14 publicaciones etiquetados con "IA"

El Protocolo de Pagos de Agentes (AP2) de Google es un estándar abierto recientemente anunciado, diseñado para permitir transacciones seguras y confiables iniciadas por agentes de IA en nombre de los usuarios. Desarrollado en colaboración con más de 60 organizaciones de pagos y tecnología (incluyendo las principales redes de pago, bancos, fintechs y empresas Web3), AP2 establece un lenguaje común para los pagos "agéneticos", es decir, compras y transacciones financieras que un agente autónomo (como un asistente de IA o un agente basado en LLM) puede realizar para un usuario. La creación de AP2 está impulsada por un cambio fundamental: tradicionalmente, los sistemas de pago en línea asumían que un humano hacía clic directamente en "comprar", pero el auge de los agentes de IA que actúan según las instrucciones del usuario rompe esta suposición. AP2 aborda los desafíos resultantes de autorización, autenticidad y rendición de cuentas en el comercio impulsado por IA, al tiempo que sigue siendo compatible con la infraestructura de pago existente. Este informe examina la arquitectura técnica de AP2, su propósito y casos de uso, integraciones con agentes de IA y proveedores de pago, consideraciones de seguridad y cumplimiento, comparaciones con protocolos existentes, implicaciones para Web3/sistemas descentralizados, y la adopción/hoja de ruta de la industria.

Arquitectura Técnica: Cómo Funciona AP2​

En su esencia, AP2 introduce un marco de transacciones criptográficamente seguro construido sobre credenciales digitales verificables (VDC), que son esencialmente objetos de datos firmados e inalterables que sirven como "contratos" digitales de lo que el usuario ha autorizado. En la terminología de AP2, estos contratos se denominan Mandatos, y forman una cadena de evidencia auditable para cada transacción. Hay tres tipos principales de mandatos en la arquitectura de AP2:

• Mandato de Intención: Captura las instrucciones o condiciones iniciales del usuario para una compra, especialmente para escenarios “sin presencia humana” (donde el agente actuará más tarde sin que el usuario esté en línea). Define el alcance de la autoridad que el usuario otorga al agente; por ejemplo, “Comprar entradas para el concierto si bajan de $200, hasta 2 entradas”. Este mandato es firmado criptográficamente por adelantado por el usuario y sirve como prueba verificable de consentimiento dentro de límites específicos.
• Mandato de Carrito: Representa los detalles finales de la transacción que el usuario ha aprobado, utilizado en escenarios “con presencia humana” o en el momento del pago. Incluye los artículos o servicios exactos, su precio y otros detalles de la compra. Cuando el agente está listo para completar la transacción (por ejemplo, después de llenar un carrito de compras), el comerciante primero firma criptográficamente el contenido del carrito (garantizando los detalles del pedido y el precio), y luego el usuario (a través de su dispositivo o interfaz de agente) aprueba para crear un Mandato de Carrito. Esto asegura lo que ves es lo que pagas, fijando el pedido final exactamente como se le presentó al usuario.
• Mandato de Pago: Una credencial separada que se envía a la red de pago (por ejemplo, red de tarjetas o banco) para indicar que un agente de IA está involucrado en la transacción. El Mandato de Pago incluye metadatos como si el usuario estuvo presente o no durante la autorización y sirve como una bandera para los sistemas de gestión de riesgos. Al proporcionar a los bancos adquirentes y emisores evidencia criptográficamente verificable de la intención del usuario, este mandato les ayuda a evaluar el contexto (por ejemplo, distinguir una compra iniciada por un agente de un fraude típico) y gestionar el cumplimiento o la responsabilidad en consecuencia.

Todos los mandatos se implementan como credenciales verificables firmadas por las claves de la parte relevante (usuario, comerciante, etc.), lo que produce una pista de auditoría no repudiable para cada transacción dirigida por un agente. En la práctica, AP2 utiliza una arquitectura basada en roles para proteger la información sensible; por ejemplo, un agente podría manejar un Mandato de Intención sin ver nunca los detalles de pago sin procesar, que solo se revelan de forma controlada cuando es necesario, preservando la privacidad. La cadena criptográfica de intención del usuario → compromiso del comerciante → autorización de pago establece la confianza entre todas las partes de que la transacción refleja las verdaderas instrucciones del usuario y de que tanto el agente como el comerciante se adhirieron a esas instrucciones.

Flujo de Transacción: Para ilustrar cómo funciona AP2 de principio a fin, considere un escenario de compra simple con un humano en el bucle:

1. Solicitud del Usuario: El usuario le pide a su agente de IA que compre un artículo o servicio en particular (por ejemplo, “Pide este par de zapatos en mi talla”).
2. Construcción del Carrito: El agente se comunica con los sistemas del comerciante (utilizando API estándar o mediante una interacción agente-a-agente) para armar un carrito de compras para el artículo especificado a un precio determinado.
3. Garantía del Comerciante: Antes de presentar el carrito al usuario, el lado del comerciante firma criptográficamente los detalles del carrito (artículo, cantidad, precio, etc.). Este paso crea una oferta firmada por el comerciante que garantiza los términos exactos (evitando cualquier cambio oculto o manipulación de precios).
4. Aprobación del Usuario: El agente muestra al usuario el carrito finalizado. El usuario confirma la compra, y esta aprobación desencadena dos firmas criptográficas del lado del usuario: una en el Mandato de Carrito (para aceptar el carrito del comerciante tal cual) y otra en el Mandato de Pago (para autorizar el pago a través del proveedor de pago elegido). Estos mandatos firmados se comparten luego con el comerciante y la red de pago, respectivamente.
5. Ejecución: Armados con el Mandato de Carrito y el Mandato de Pago, el comerciante y el proveedor de pago proceden a ejecutar la transacción de forma segura. Por ejemplo, el comerciante envía la solicitud de pago junto con la prueba de aprobación del usuario a la red de pago (red de tarjetas, banco, etc.), que puede verificar el Mandato de Pago. El resultado es una transacción de compra completada con una pista de auditoría criptográfica que vincula la intención del usuario con el pago final.

Este flujo demuestra cómo AP2 construye confianza en cada paso de una compra impulsada por IA. El comerciante tiene prueba criptográfica de exactamente lo que el usuario acordó comprar y a qué precio, y el emisor/banco tiene prueba de que el usuario autorizó ese pago, aunque un agente de IA facilitó el proceso. En caso de disputas o errores, los mandatos firmados actúan como evidencia clara, ayudando a determinar la responsabilidad (por ejemplo, si el agente se desvió de las instrucciones o si un cargo no fue lo que el usuario aprobó). En esencia, la arquitectura de AP2 asegura que la intención verificable del usuario – en lugar de la confianza en el comportamiento del agente – sea la base de la transacción, reduciendo en gran medida la ambigüedad.

Propósito y Casos de Uso para AP2​

Por qué se necesita AP2: El propósito principal de AP2 es resolver los problemas emergentes de confianza y seguridad que surgen cuando los agentes de IA pueden gastar dinero en nombre de los usuarios. Google y sus socios identificaron varias preguntas clave que la infraestructura de pago actual no puede responder adecuadamente cuando un agente autónomo está involucrado:

• Autorización: ¿Cómo probar que un usuario realmente le dio permiso al agente para realizar una compra específica? (En otras palabras, asegurar que el agente no esté comprando cosas sin el consentimiento informado del usuario).
• Autenticidad: ¿Cómo puede un comerciante saber que la solicitud de compra de un agente es genuina y refleja la verdadera intención del usuario, en lugar de un error o una alucinación de la IA?
• Rendición de Cuentas: Si ocurre una transacción fraudulenta o incorrecta a través de un agente, ¿quién es el responsable: el usuario, el comerciante, el proveedor de pago o el creador del agente de IA?

Sin una solución, estas incertidumbres crean una "crisis de confianza" en torno al comercio dirigido por agentes. La misión de AP2 es proporcionar esa solución estableciendo un protocolo uniforme para transacciones seguras de agentes. Al introducir mandatos estandarizados y pruebas de intención, AP2 evita un ecosistema fragmentado donde cada empresa inventa sus propios métodos de pago de agentes ad-hoc. En cambio, cualquier agente de IA compatible puede interactuar con cualquier comerciante/proveedor de pago compatible bajo un conjunto común de reglas y verificaciones. Esta consistencia no solo evita la confusión del usuario y del comerciante, sino que también brinda a las instituciones financieras una forma clara de gestionar el riesgo para los pagos iniciados por agentes, en lugar de lidiar con un mosaico de enfoques propietarios. En resumen, el propósito de AP2 es ser una capa de confianza fundamental que permita que la "economía de agentes" crezca sin romper el ecosistema de pagos.

Casos de Uso Previstos: Al resolver los problemas anteriores, AP2 abre la puerta a nuevas experiencias comerciales y casos de uso que van más allá de lo que es posible con un humano haciendo clic manualmente en las compras. Algunos ejemplos de comercio habilitado por agentes que AP2 admite incluyen:

• Compras más Inteligentes: Un cliente puede instruir a su agente: “Quiero esta chaqueta de invierno en verde, y estoy dispuesto a pagar hasta un 20% por encima del precio actual por ella”. Armado con un Mandato de Intención que codifica estas condiciones, el agente monitoreará continuamente los sitios web o bases de datos de los minoristas. En el momento en que la chaqueta esté disponible en verde (y dentro del umbral de precio), el agente ejecuta automáticamente una compra con una transacción segura y firmada, capturando una venta que de otro modo se habría perdido. Toda la interacción, desde la solicitud inicial del usuario hasta el pago automatizado, se rige por los mandatos de AP2, lo que garantiza que el agente solo compre exactamente lo que se autorizó.
• Ofertas Personalizadas: Un usuario le dice a su agente que está buscando un producto específico (por ejemplo, una bicicleta nueva) de un comerciante en particular para un próximo viaje. El agente puede compartir este interés (dentro de los límites de un Mandato de Intención) con el propio agente de IA del comerciante, incluyendo el contexto relevante como la fecha del viaje. El agente del comerciante, conociendo la intención y el contexto del usuario, podría responder con un paquete o descuento personalizado, por ejemplo, “bicicleta + casco + portaequipajes con un 15% de descuento, disponible durante las próximas 48 horas”. Usando AP2, el agente del usuario puede aceptar y completar esta oferta personalizada de forma segura, convirtiendo una simple consulta en una venta más valiosa para el comerciante.
• Tareas Coordinadas: Un usuario que planifica una tarea compleja (por ejemplo, un viaje de fin de semana) la delega por completo: “Resérvame un vuelo y un hotel para estas fechas con un presupuesto total de $700”. El agente puede interactuar con los agentes de múltiples proveedores de servicios (aerolíneas, hoteles, plataformas de viaje) para encontrar una combinación que se ajuste al presupuesto. Una vez que se identifica un paquete de vuelo y hotel adecuado, el agente utiliza AP2 para ejecutar múltiples reservas de una sola vez, cada una firmada criptográficamente (por ejemplo, emitiendo Mandatos de Carrito separados para la aerolínea y el hotel, ambos autorizados bajo el Mandato de Intención del usuario). AP2 garantiza que todas las partes de esta transacción coordinada ocurran según lo aprobado, e incluso permite la ejecución simultánea para que los boletos y las reservas se realicen juntos sin riesgo de que una parte falle a mitad de camino.

Estos escenarios ilustran solo algunos de los casos de uso previstos de AP2. De manera más amplia, el diseño flexible de AP2 admite tanto los flujos de comercio electrónico convencionales como modelos de comercio completamente nuevos. Por ejemplo, AP2 puede facilitar servicios tipo suscripción (un agente te mantiene abastecido de elementos esenciales comprando cuando se cumplen las condiciones), compras impulsadas por eventos (comprar entradas o artículos en el instante en que ocurre un evento desencadenante), negociaciones de agentes grupales (agentes de múltiples usuarios agrupando mandatos para negociar un acuerdo grupal), y muchos otros patrones emergentes. En cada caso, el hilo conductor es que AP2 proporciona el marco de confianza – autorización clara del usuario y auditabilidad criptográfica – que permite que estas transacciones impulsadas por agentes se realicen de forma segura. Al manejar la capa de confianza y verificación, AP2 permite a los desarrolladores y empresas centrarse en innovar nuevas experiencias de comercio de IA sin reinventar la seguridad de los pagos desde cero.

Integración con Agentes, LLMs y Proveedores de Pago​

AP2 está explícitamente diseñado para integrarse sin problemas con los frameworks de agentes de IA y con los sistemas de pago existentes, actuando como un puente entre ambos. Google ha posicionado AP2 como una extensión de sus estándares de protocolo Agent2Agent (A2A) y Model Context Protocol (MCP). En otras palabras, si A2A proporciona un lenguaje genérico para que los agentes comuniquen tareas y MCP estandariza cómo los modelos de IA incorporan contexto/herramientas, entonces AP2 añade una capa de transacciones encima para el comercio. Los protocolos son complementarios: A2A maneja la comunicación agente-a-agente (permitiendo, por ejemplo, que un agente de compras hable con el agente de un comerciante), mientras que AP2 maneja la autorización de pago agente-a-comerciante dentro de esas interacciones. Debido a que AP2 es abierto y no propietario, está diseñado para ser agnóstico al framework: los desarrolladores pueden usarlo con el propio Kit de Desarrollo de Agentes (ADK) de Google o cualquier biblioteca de agentes de IA, y de manera similar puede funcionar con varios modelos de IA, incluyendo LLMs. Un agente basado en LLM, por ejemplo, podría usar AP2 generando e intercambiando las cargas útiles de mandato requeridas (guiado por la especificación AP2) en lugar de solo texto de forma libre. Al imponer un protocolo estructurado, AP2 ayuda a transformar la intención de alto nivel de un agente de IA (que podría provenir del razonamiento de un LLM) en transacciones concretas y seguras.

En el lado de los pagos, AP2 fue construido en concierto con los proveedores y estándares de pago tradicionales, en lugar de como un sistema de reemplazo. El protocolo es agnóstico al método de pago, lo que significa que puede admitir una variedad de rieles de pago – desde redes de tarjetas de crédito/débito hasta transferencias bancarias y billeteras digitales – como método subyacente para mover fondos. En su versión inicial, AP2 enfatiza la compatibilidad con pagos con tarjeta, ya que son los más comunes en el comercio en línea. El Mandato de Pago de AP2 está diseñado para conectarse al flujo de procesamiento de tarjetas existente: proporciona datos adicionales a la red de pago (por ejemplo, Visa, Mastercard, Amex) y al banco emisor de que un agente de IA está involucrado y si el usuario estuvo presente, complementando así los controles de detección de fraude y autorización existentes. Esencialmente, AP2 no procesa el pago en sí; aumenta la solicitud de pago con prueba criptográfica de la intención del usuario. Esto permite a los proveedores de pago tratar las transacciones iniciadas por agentes con la precaución o velocidad adecuadas (por ejemplo, un emisor podría aprobar una compra de aspecto inusual si ve un mandato AP2 válido que demuestre que el usuario la pre-aprobó). En particular, Google y sus socios planean evolucionar AP2 para admitir también métodos de pago "push" – como transferencias bancarias en tiempo real (como los sistemas UPI de India o PIX de Brasil) – y otros tipos de pagos digitales emergentes. Esto indica que la integración de AP2 se expandirá más allá de las tarjetas, alineándose con las tendencias de pago modernas en todo el mundo.

Para los comerciantes y procesadores de pagos, integrar AP2 significaría admitir los mensajes de protocolo adicionales (mandatos) y verificar las firmas. Muchas grandes plataformas de pago ya están involucradas en la configuración de AP2, por lo que podemos esperar que desarrollen soporte para ello. Por ejemplo, empresas como Adyen, Worldpay, Paypal, Stripe (no mencionadas explícitamente en el blog pero probablemente interesadas) y otras podrían incorporar AP2 en sus API o SDK de pago, permitiendo que un agente inicie un pago de manera estandarizada. Debido a que AP2 es una especificación abierta en GitHub con implementaciones de referencia, los proveedores de pago y las plataformas tecnológicas pueden comenzar a experimentar con ella de inmediato. Google también ha mencionado un Mercado de Agentes de IA donde se pueden listar agentes de terceros; se espera que estos agentes admitan AP2 para cualquier capacidad transaccional. En la práctica, una empresa que construye un asistente de ventas de IA o un agente de adquisiciones podría listarlo en este mercado, y gracias a AP2, ese agente puede realizar compras u pedidos de manera confiable.

Finalmente, la historia de integración de AP2 se beneficia de su amplio respaldo de la industria. Al codesarrollar el protocolo con las principales instituciones financieras y empresas tecnológicas, Google se aseguró de que AP2 se alinee con las reglas y requisitos de cumplimiento existentes de la industria. La colaboración con redes de pago (por ejemplo, Mastercard, UnionPay), emisores (por ejemplo, American Express), fintechs (por ejemplo, Revolut, Paypal), actores de comercio electrónico (por ejemplo, Etsy) e incluso proveedores de identidad/seguridad (por ejemplo, Okta, Cloudflare) sugiere que AP2 está siendo diseñado para encajar en sistemas del mundo real con una fricción mínima. Estos stakeholders aportan experiencia en áreas como KYC (regulaciones Conozca a su Cliente), prevención de fraude y privacidad de datos, lo que ayuda a AP2 a abordar esas necesidades de forma predeterminada. En resumen, AP2 está construido para ser amigable para agentes y amigable para proveedores de pago: extiende los protocolos de agentes de IA existentes para manejar transacciones, y se superpone a las redes de pago existentes para utilizar su infraestructura mientras agrega las garantías de confianza necesarias.

Consideraciones de Seguridad, Cumplimiento e Interoperabilidad​

La seguridad y la confianza son el corazón del diseño de AP2. El uso de criptografía por parte del protocolo (firmas digitales en los mandatos) garantiza que cada acción crítica en una transacción agénetica sea verificable y rastreable. Este no repudio es crucial: ni el usuario ni el comerciante pueden negar posteriormente lo que se autorizó y acordó, ya que los mandatos sirven como registros seguros. Un beneficio directo es la prevención de fraude y la resolución de disputas: con AP2, si un agente malicioso o con errores intenta una compra no autorizada, la falta de un mandato válido firmado por el usuario sería evidente, y la transacción puede ser rechazada o revertida. Por el contrario, si un usuario afirma "Nunca aprobé esta compra", pero existe un Mandato de Carrito con su firma criptográfica, el comerciante y el emisor tienen pruebas sólidas para respaldar el cargo. Esta claridad de responsabilidad responde a una importante preocupación de cumplimiento para la industria de pagos.

Autorización y Privacidad: AP2 impone un paso (o pasos) de autorización explícita del usuario para las transacciones dirigidas por agentes, lo que se alinea con las tendencias regulatorias como la autenticación fuerte del cliente. El principio de Control del Usuario incorporado en AP2 significa que un agente no puede gastar fondos a menos que el usuario (o alguien delegado por el usuario) haya proporcionado una instrucción verificable para hacerlo. Incluso en escenarios totalmente autónomos, el usuario predefine las reglas a través de un Mandato de Intención. Este enfoque puede verse como análogo a otorgar un poder notarial al agente para transacciones específicas, pero de una manera digitalmente firmada y granular. Desde una perspectiva de privacidad, AP2 es consciente del intercambio de datos: el protocolo utiliza una arquitectura de datos basada en roles para garantizar que la información sensible (como credenciales de pago o detalles personales) solo se comparta con las partes que la necesitan absolutamente. Por ejemplo, un agente podría enviar un Mandato de Carrito a un comerciante que contenga información de artículos y precios, pero el número de tarjeta real del usuario solo podría compartirse a través del Mandato de Pago con el procesador de pagos, no con el agente o el comerciante. Esto minimiza la exposición innecesaria de datos, lo que ayuda al cumplimiento de las leyes de privacidad y las reglas PCI-DSS para el manejo de datos de pago.

Cumplimiento y Estándares: Debido a que AP2 se desarrolló con la aportación de entidades financieras establecidas, ha sido diseñado para cumplir o complementar los estándares de cumplimiento existentes en los pagos. El protocolo no elude los flujos de autorización de pago habituales; en cambio, los aumenta con evidencia y banderas adicionales. Esto significa que las transacciones de AP2 aún pueden aprovechar los sistemas de detección de fraude, los controles 3-D Secure o cualquier control regulatorio requerido, con los mandatos de AP2 actuando como factores de autenticación adicionales o señales de contexto. Por ejemplo, un banco podría tratar un Mandato de Pago como una firma digital del cliente en una transacción, lo que podría agilizar el cumplimiento de los requisitos de consentimiento del usuario. Además, los diseñadores de AP2 mencionan explícitamente trabajar "en concierto con las reglas y estándares de la industria". Podemos inferir que, a medida que AP2 evolucione, podría ser llevado a organismos de estándares formales (como el W3C, EMVCo o ISO) para garantizar que se alinee con los estándares financieros globales. Google ha declarado su compromiso con una evolución abierta y colaborativa de AP2, posiblemente a través de organizaciones de estándares. Este proceso abierto ayudará a resolver cualquier preocupación regulatoria y a lograr una amplia aceptación, de manera similar a cómo los estándares de pago anteriores (tarjetas con chip EMV, 3-D Secure, etc.) se sometieron a una colaboración a nivel de la industria.

Interoperabilidad: Evitar la fragmentación es un objetivo clave de AP2. Para ello, el protocolo se publica abiertamente y está disponible para que cualquiera lo implemente o integre. No está vinculado a los servicios de Google Cloud; de hecho, AP2 es de código abierto (licencia Apache-2) y la especificación más el código de referencia están en un repositorio público de GitHub. Esto fomenta la interoperabilidad porque múltiples proveedores pueden adoptar AP2 y aún así hacer que sus sistemas funcionen juntos. Ya se destaca el principio de interoperabilidad: AP2 es una extensión de protocolos abiertos existentes (A2A, MCP) y no es propietario, lo que significa que fomenta un ecosistema competitivo de implementaciones en lugar de una solución de un solo proveedor. En términos prácticos, un agente de IA construido por la Compañía A podría iniciar una transacción con un sistema de comerciante de la Compañía B si ambos siguen AP2; ninguna de las partes está bloqueada en una sola plataforma.

Una posible preocupación es asegurar una adopción consistente: si algunos actores importantes eligieran un protocolo diferente o un enfoque cerrado, la fragmentación aún podría ocurrir. Sin embargo, dada la amplia coalición detrás de AP2, parece estar preparado para convertirse en un estándar de facto. La inclusión de muchas empresas centradas en la identidad y la seguridad (por ejemplo, Okta, Cloudflare, Ping Identity) en el ecosistema de AP2 Figura: Más de 60 empresas de finanzas, tecnología y cripto están colaborando en AP2 (lista parcial de socios). sugiere que la interoperabilidad y la seguridad se están abordando conjuntamente. Estos socios pueden ayudar a integrar AP2 en los flujos de trabajo de verificación de identidad y las herramientas de prevención de fraude, asegurando que una transacción de AP2 pueda ser confiable en todos los sistemas.

Desde el punto de vista tecnológico, el uso de técnicas criptográficas ampliamente aceptadas por AP2 (probablemente credenciales verificables basadas en JSON-LD o JWT, firmas de clave pública, etc.) lo hace compatible con la infraestructura de seguridad existente. Las organizaciones pueden usar su PKI (Infraestructura de Clave Pública) existente para administrar claves para firmar mandatos. AP2 también parece anticipar la integración con sistemas de identidad descentralizada: Google menciona que AP2 crea oportunidades para innovar en áreas como la identidad descentralizada para la autorización de agentes. Esto significa que, en el futuro, AP2 podría aprovechar los estándares DID (Identificador Descentralizado) o la verificación de identificadores descentralizados para identificar agentes y usuarios de manera confiable. Tal enfoque mejoraría aún más la interoperabilidad al no depender de ningún proveedor de identidad único. En resumen, AP2 enfatiza la seguridad a través de la criptografía y la responsabilidad clara, tiene como objetivo estar listo para el cumplimiento por diseño y promueve la interoperabilidad a través de su naturaleza de estándar abierto y el amplio apoyo de la industria.

Comparación con Protocolos Existentes​

AP2 es un protocolo novedoso que aborda una brecha que los marcos de pago y agentes existentes no han cubierto: permitir que los agentes autónomos realicen pagos de manera segura y estandarizada. En términos de protocolos de comunicación de agentes, AP2 se basa en trabajos anteriores como el protocolo Agent2Agent (A2A). A2A (de código abierto a principios de 2025) permite que diferentes agentes de IA se comuniquen entre sí, independientemente de sus marcos subyacentes. Sin embargo, A2A por sí solo no define cómo los agentes deben realizar transacciones o pagos; se trata más de la negociación de tareas y el intercambio de datos. AP2 amplía este panorama al agregar una capa de transacción que cualquier agente puede usar cuando una conversación conduce a una compra. En esencia, AP2 puede verse como complementario a A2A y MCP, en lugar de superponerse: A2A cubre los aspectos de comunicación y colaboración, MCP cubre el uso de herramientas/API externas, y AP2 cubre pagos y comercio. Juntos, forman una pila de estándares para una futura "economía de agentes". Este enfoque modular es algo análogo a los protocolos de internet: por ejemplo, HTTP para la comunicación de datos y SSL/TLS para la seguridad; aquí A2A podría ser como el HTTP de los agentes, y AP2 la capa transaccional segura encima para el comercio.

Al comparar AP2 con los protocolos y estándares de pago tradicionales, existen tanto paralelismos como diferencias. Los pagos en línea tradicionales (pagos con tarjeta de crédito, transacciones de PayPal, etc.) suelen implicar protocolos como HTTPS para una transmisión segura, y estándares como PCI DSS para el manejo de datos de tarjetas, además de posiblemente 3-D Secure para una autenticación de usuario adicional. Estos asumen un flujo impulsado por el usuario (el usuario hace clic y quizás ingresa un código de un solo uso). AP2, por el contrario, introduce una forma para que un tercero (el agente) participe en el flujo sin socavar la seguridad. Se podría comparar el concepto de mandato de AP2 con una extensión de la autoridad delegada al estilo OAuth, pero aplicada a los pagos. En OAuth, un usuario puede otorgar a una aplicación acceso limitado a una cuenta a través de tokens; de manera similar en AP2, un usuario otorga a un agente autoridad para gastar bajo ciertas condiciones a través de mandatos. La diferencia clave es que los "tokens" de AP2 (mandatos) son instrucciones específicas y firmadas para transacciones financieras, lo que es más granular que las autorizaciones de pago existentes.

Otro punto de comparación es cómo AP2 se relaciona con los flujos de pago de comercio electrónico existentes. Por ejemplo, muchos sitios de comercio electrónico utilizan protocolos como la API de Solicitud de Pago de W3C o SDK específicos de la plataforma para agilizar los pagos. Estos principalmente estandarizan cómo los navegadores o aplicaciones recopilan información de pago de un usuario, mientras que AP2 estandariza cómo un agente probaría la intención del usuario a un comerciante y procesador de pagos. El enfoque de AP2 en la intención verificable y el no repudio lo distingue de las API de pago más simples. Está agregando una capa adicional de confianza sobre las redes de pago. Se podría decir que AP2 no está reemplazando las redes de pago (Visa, ACH, blockchain, etc.), sino que las está aumentando. El protocolo admite explícitamente todo tipo de métodos de pago (incluso cripto), por lo que se trata más de estandarizar la interacción del agente con estos sistemas, no de crear un nuevo riel de pago desde cero.

En el ámbito de los protocolos de seguridad y autenticación, AP2 comparte cierto espíritu con elementos como las firmas digitales en las tarjetas con chip EMV o la notarización en los contratos digitales. Por ejemplo, las transacciones con tarjeta con chip EMV generan criptogramas para probar que la tarjeta estuvo presente; AP2 genera pruebas criptográficas de que el agente del usuario fue autorizado. Ambos tienen como objetivo prevenir el fraude, pero el alcance de AP2 es la relación agente-usuario y la mensajería agente-comerciante, que ningún estándar de pago existente aborda. Otra comparación emergente es con la abstracción de cuentas en cripto (por ejemplo, ERC-4337), donde los usuarios pueden autorizar acciones de billetera preprogramadas. Las billeteras criptográficas se pueden configurar para permitir ciertas transacciones automatizadas (como el pago automático de una suscripción a través de un contrato inteligente), pero estas suelen estar confinadas a un entorno de blockchain. AP2, por otro lado, aspira a ser multiplataforma: puede aprovechar blockchain para algunos pagos (a través de sus extensiones) pero también funciona con bancos tradicionales.

Todavía no existe un protocolo "competidor" directo de AP2 en la industria de pagos convencional; parece ser el primer esfuerzo concertado para un estándar abierto para pagos de agentes de IA. Pueden surgir intentos propietarios (o ya pueden estar en curso dentro de empresas individuales), pero el amplio apoyo de AP2 le da una ventaja para convertirse en el estándar. Vale la pena señalar que IBM y otros tienen un Protocolo de Comunicación de Agentes (ACP) e iniciativas similares para la interoperabilidad de agentes, pero estas no abarcan el aspecto de pago de la manera integral en que lo hace AP2. En todo caso, AP2 podría integrarse o aprovechar esos esfuerzos (por ejemplo, los frameworks de agentes de IBM podrían implementar AP2 para cualquier tarea comercial).

En resumen, AP2 se distingue por apuntar a la intersección única de la IA y los pagos: donde los protocolos de pago más antiguos asumían un usuario humano, AP2 asume un intermediario de IA y llena la brecha de confianza que resulta. Extiende, en lugar de entrar en conflicto con, los procesos de pago existentes, y complementa los protocolos de agentes existentes como A2A. En el futuro, se podría ver a AP2 utilizándose junto con estándares establecidos; por ejemplo, un Mandato de Carrito de AP2 podría funcionar en conjunto con una llamada a la API de una pasarela de pago tradicional, o un Mandato de Pago de AP2 podría adjuntarse a un mensaje ISO 8583 en la banca. La naturaleza abierta de AP2 también significa que si surgen enfoques alternativos, AP2 podría potencialmente absorberlos o alinearse con ellos a través de la colaboración comunitaria. En esta etapa, AP2 está estableciendo una base que no existía antes, siendo efectivamente pionero en una nueva capa de protocolo en la pila de IA y pagos.

Implicaciones para Web3 y Sistemas Descentralizados​

Desde el principio, AP2 ha sido diseñado para ser inclusivo de los pagos basados en Web3 y criptomonedas. El protocolo reconoce que el comercio futuro abarcará tanto los canales fiduciarios tradicionales como las redes blockchain descentralizadas. Como se señaló anteriormente, AP2 admite tipos de pago que van desde tarjetas de crédito y transferencias bancarias hasta stablecoins y criptomonedas. De hecho, junto con el lanzamiento de AP2, Google anunció una extensión específica para pagos criptográficos llamada A2A x402. Esta extensión, desarrollada en colaboración con actores de la industria cripto como Coinbase, la Ethereum Foundation y MetaMask, es una "solución lista para producción para pagos criptográficos basados en agentes". El nombre "x402" es un homenaje al código de estado HTTP 402 "Pago Requerido", que nunca fue ampliamente utilizado en la Web; la extensión criptográfica de AP2 efectivamente revive el espíritu de HTTP 402 para agentes descentralizados que desean cobrarse o pagarse entre sí en la cadena. En términos prácticos, la extensión x402 adapta el concepto de mandato de AP2 a las transacciones de blockchain. Por ejemplo, un agente podría tener un Mandato de Intención firmado por un usuario y luego ejecutar un pago en cadena (por ejemplo, enviar una stablecoin) una vez que se cumplan las condiciones, adjuntando la prueba del mandato a esa transacción en cadena. Esto une el marco de confianza fuera de la cadena de AP2 con la naturaleza sin confianza de blockchain, ofreciendo lo mejor de ambos mundos: un pago en cadena que las partes fuera de la cadena (usuarios, comerciantes) pueden confiar que fue autorizado por el usuario.

La sinergia entre AP2 y Web3 es evidente en la lista de colaboradores. Intercambios de criptomonedas (Coinbase), fundaciones de blockchain (Ethereum Foundation), billeteras criptográficas (MetaMask) y startups de Web3 (por ejemplo, Mysten Labs de Sui, Lightspark para Lightning Network) están involucrados en el desarrollo de AP2. Su participación sugiere que AP2 se considera complementario a las finanzas descentralizadas en lugar de competitivo. Al crear una forma estándar para que los agentes de IA interactúen con los pagos criptográficos, AP2 podría impulsar un mayor uso de las criptomonedas en aplicaciones impulsadas por IA. Por ejemplo, un agente de IA podría usar AP2 para cambiar sin problemas entre pagar con tarjeta de crédito o pagar con una stablecoin, dependiendo de la preferencia del usuario o la aceptación del comerciante. La extensión A2A x402 permite específicamente a los agentes monetizar o pagar servicios a través de medios en cadena, lo que podría ser crucial en los mercados descentralizados del futuro. Sugiere que los agentes que posiblemente operen como actores económicos autónomos en blockchain (un concepto al que algunos se refieren como DACs o DAOs) podrán manejar los pagos requeridos para los servicios (como pagar una pequeña tarifa a otro agente por información). AP2 podría proporcionar la lengua franca para tales transacciones, asegurando que incluso en una red descentralizada, el agente tenga un mandato comprobable de lo que está haciendo.

En términos de competencia, uno podría preguntar: ¿las soluciones puramente descentralizadas hacen que AP2 sea innecesario, o viceversa? Es probable que AP2 coexista con las soluciones Web3 en un enfoque por capas. Las finanzas descentralizadas ofrecen ejecución sin confianza (contratos inteligentes, etc.), pero no resuelven inherentemente el problema de "¿Un IA tuvo permiso de un humano para hacer esto?". AP2 aborda ese vínculo de confianza humano-a-IA, que sigue siendo importante incluso si el pago en sí está en la cadena. En lugar de competir con los protocolos de blockchain, AP2 puede verse como un puente entre ellos y el mundo fuera de la cadena. Por ejemplo, un contrato inteligente podría aceptar una determinada transacción solo si incluye una referencia a una firma de mandato AP2 válida, algo que podría implementarse para combinar la prueba de intención fuera de la cadena con la aplicación en cadena. Por el contrario, si existen marcos de agentes cripto-nativos (algunos proyectos de blockchain exploran agentes autónomos que operan con fondos criptográficos), podrían desarrollar sus propios métodos de autorización. Sin embargo, el amplio apoyo de la industria de AP2 podría llevar incluso a esos proyectos a adoptar o integrarse con AP2 para mantener la coherencia.

Otro ángulo es la identidad y credenciales descentralizadas. El uso de credenciales verificables por parte de AP2 está muy en línea con el enfoque de Web3 hacia la identidad (por ejemplo, DIDs y VCs estandarizados por el W3C). Esto significa que AP2 podría conectarse a sistemas de identidad descentralizada; por ejemplo, el DID de un usuario podría usarse para firmar un mandato AP2, que un comerciante podría verificar contra una blockchain o un hub de identidad. La mención de explorar la identidad descentralizada para la autorización de agentes refuerza que AP2 puede aprovechar las innovaciones de identidad de Web3 para verificar las identidades de agentes y usuarios de manera descentralizada, en lugar de depender únicamente de autoridades centralizadas. Este es un punto de sinergia, ya que tanto AP2 como Web3 tienen como objetivo dar a los usuarios más control y pruebas criptográficas de sus acciones.

Posibles conflictos podrían surgir solo si se concibe un ecosistema de comercio totalmente descentralizado sin ningún papel para los grandes intermediarios; en ese escenario, ¿podría AP2 (inicialmente impulsado por Google y sus socios) ser demasiado centralizado o gobernado por actores tradicionales? Es importante señalar que AP2 es de código abierto y está destinado a ser estandarizable, por lo que no es propietario de Google. Esto lo hace más aceptable para la comunidad Web3, que valora los protocolos abiertos. Si AP2 se adopta ampliamente, podría reducir la necesidad de protocolos de pago separados específicos de Web3 para agentes, unificando así los esfuerzos. Por otro lado, algunos proyectos de blockchain podrían preferir mecanismos de autorización puramente en cadena (como billeteras multifirma o lógica de custodia en cadena) para transacciones de agentes, especialmente en entornos sin confianza y sin autoridades centralizadas. Esos podrían verse como enfoques alternativos, pero probablemente seguirían siendo un nicho a menos que puedan interactuar con sistemas fuera de la cadena. AP2, al cubrir ambos mundos, podría en realidad acelerar la adopción de Web3 al hacer de las criptomonedas solo otro método de pago que un agente de IA puede usar sin problemas. De hecho, un socio señaló que “las stablecoins proporcionan una solución obvia a los desafíos de escalado [para] sistemas agéneticos con infraestructura heredada”, destacando que las criptomonedas pueden complementar a AP2 en el manejo de la escala o escenarios transfronterizos. Mientras tanto, el líder de ingeniería de Coinbase comentó que llevar la extensión criptográfica x402 a AP2 “tenía sentido: es un campo de juego natural para los agentes... es emocionante ver que los agentes que se pagan entre sí resuenan en la comunidad de IA”. Esto implica una visión en la que los agentes de IA que realizan transacciones a través de redes criptográficas no es solo una idea teórica, sino un resultado esperado, con AP2 actuando como catalizador.

En resumen, AP2 es muy relevante para Web3: incorpora los pagos criptográficos como un ciudadano de primera clase y se alinea con los estándares de identidad y credenciales descentralizadas. En lugar de competir directamente con los protocolos de pago descentralizados, AP2 probablemente interoperará con ellos, proporcionando la capa de autorización mientras los sistemas descentralizados manejan la transferencia de valor. A medida que la línea entre las finanzas tradicionales y las criptomonedas se difumina (con stablecoins, CBDCs, etc.), un protocolo unificado como AP2 podría servir como un adaptador universal entre agentes de IA y cualquier forma de dinero, centralizada o descentralizada.

Adopción en la Industria, Asociaciones y Hoja de Ruta​

Una de las mayores fortalezas de AP2 es el amplio respaldo de la industria que tiene, incluso en esta etapa temprana. Google Cloud anunció que está “colaborando con un grupo diverso de más de 60 organizaciones” en AP2. Estas incluyen las principales redes de tarjetas de crédito (por ejemplo, Mastercard, American Express, JCB, UnionPay), líderes en fintech y procesadores de pagos (PayPal, Worldpay, Adyen, Checkout.com, competidores de Stripe), comercio electrónico y mercados en línea (Etsy, Shopify (a través de socios como Stripe u otros), Lazada, Zalora), empresas de tecnología empresarial (Salesforce, ServiceNow, Oracle posiblemente a través de socios, Dell, Red Hat), empresas de identidad y seguridad (Okta, Ping Identity, Cloudflare), firmas de consultoría (Deloitte, Accenture), y organizaciones de cripto/Web3 (Coinbase, Ethereum Foundation, MetaMask, Mysten Labs, Lightspark), entre otras. Una gama tan amplia de participantes es un fuerte indicador del interés de la industria y la probable adopción. Muchos de estos socios han expresado públicamente su apoyo. Por ejemplo, el Co-CEO de Adyen destacó la necesidad de un "libro de reglas común" para el comercio agénetico y ve a AP2 como una extensión natural de su misión de apoyar a los comerciantes con nuevos bloques de construcción de pago. El vicepresidente ejecutivo de American Express declaró que AP2 es importante para “la próxima generación de pagos digitales” donde la confianza y la rendición de cuentas son primordiales. El equipo de Coinbase, como se señaló, está entusiasmado con la integración de pagos criptográficos en AP2. Este coro de apoyo muestra que muchos en la industria ven a AP2 como el estándar probable para los pagos impulsados por IA, y están ansiosos por darle forma para asegurar que cumpla con sus requisitos.

Desde el punto de vista de la adopción, AP2 se encuentra actualmente en la etapa de especificación e implementación temprana (anunciado en septiembre de 2025). La especificación técnica completa, la documentación y algunas implementaciones de referencia (en lenguajes como Python) están disponibles en el GitHub del proyecto para que los desarrolladores experimenten con ellas. Google también ha indicado que AP2 se incorporará a sus productos y servicios para agentes. Un ejemplo notable es el Mercado de Agentes de IA mencionado anteriormente: esta es una plataforma donde se pueden ofrecer agentes de IA de terceros a los usuarios (probablemente parte del ecosistema de IA generativa de Google). Google dice que muchos socios que construyen agentes los pondrán a disposición en el mercado con "nuevas experiencias transaccionales habilitadas por AP2". Esto implica que a medida que el mercado se lance o crezca, AP2 será la columna vertebral para cualquier agente que necesite realizar una transacción, ya sea comprando software del Google Cloud Marketplace de forma autónoma o un agente comprando bienes/servicios para un usuario. Casos de uso empresariales como la adquisición autónoma (un agente comprando a otro en nombre de una empresa) y el escalado automático de licencias se han mencionado específicamente como áreas que AP2 podría facilitar pronto.

En cuanto a la hoja de ruta, la documentación de AP2 y el anuncio de Google dan algunas indicaciones claras:

• Corto plazo: Continuar el desarrollo abierto del protocolo con la aportación de la comunidad. El repositorio de GitHub se actualizará con implementaciones de referencia adicionales y mejoras a medida que se realicen pruebas en el mundo real. Podemos esperar que surjan bibliotecas/SDK, lo que facilitará la integración de AP2 en aplicaciones de agentes. Además, las empresas asociadas podrían llevar a cabo programas piloto iniciales o pruebas de concepto. Dado que muchas grandes empresas de pago están involucradas, podrían probar AP2 en entornos controlados (por ejemplo, una opción de pago habilitada para AP2 en una pequeña beta de usuarios).
• Estándares y Gobernanza: Google ha expresado su compromiso de mover AP2 a un modelo de gobernanza abierta, posiblemente a través de organismos de estándares. Esto podría significar enviar AP2 a organizaciones como la Linux Foundation (como se hizo con el protocolo A2A) o formar un consorcio para mantenerlo. La Linux Foundation, el W3C o incluso organismos como ISO/TC68 (servicios financieros) podrían estar en los planes para formalizar AP2. Una gobernanza abierta tranquilizaría a la industria de que AP2 no está bajo el control de una sola empresa y seguirá siendo neutral e inclusivo.
• Expansión de Funcionalidades: Técnicamente, la hoja de ruta incluye la expansión del soporte a más tipos de pago y casos de uso. Como se señaló en la especificación, después de las tarjetas, el enfoque se desplazará a los pagos "push" como transferencias bancarias y esquemas de pago locales en tiempo real, y monedas digitales. Esto significa que AP2 describirá cómo funciona un Mandato de Intención/Carrito/Pago para, por ejemplo, una transferencia bancaria directa o una transferencia de billetera criptográfica, donde el flujo es un poco diferente al de los retiros con tarjeta. La extensión A2A x402 es una de esas expansiones para cripto; de manera similar, podríamos ver una extensión para API de banca abierta o una para escenarios de facturación B2B.
• Mejoras de Seguridad y Cumplimiento: A medida que las transacciones reales comiencen a fluir a través de AP2, habrá un escrutinio por parte de los reguladores e investigadores de seguridad. El proceso abierto probablemente iterará para hacer los mandatos aún más robustos (por ejemplo, asegurando que los formatos de mandato estén estandarizados, posiblemente usando el formato de Credenciales Verificables del W3C, etc.). La integración con soluciones de identidad (quizás aprovechando la biometría para la firma de mandatos por parte del usuario, o vinculando mandatos a billeteras de identidad digital) podría ser parte de la hoja de ruta para mejorar la confianza.
• Herramientas del Ecosistema: Es probable que surja un ecosistema. Ya, las startups están notando lagunas; por ejemplo, el análisis de Vellum.ai menciona una startup llamada Autumn que está construyendo una "infraestructura de facturación para IA", esencialmente herramientas sobre Stripe para manejar precios complejos para servicios de IA. A medida que AP2 gane tracción, podemos esperar que aparezcan más herramientas como pasarelas de pago centradas en agentes, paneles de control de gestión de mandatos, servicios de verificación de identidad de agentes, etc. La participación de Google significa que AP2 también podría integrarse en sus productos de Cloud; imagine el soporte de AP2 en las herramientas de Dialogflow o Vertex AI Agents, lo que permitiría con un solo clic que un agente maneje transacciones (con todas las claves y certificados necesarios administrados en Google Cloud).

En general, la trayectoria de AP2 recuerda a otros estándares importantes de la industria: un lanzamiento inicial con un patrocinador fuerte (Google), una amplia coalición industrial, código de referencia de código abierto, seguido de mejoras iterativas y adopción gradual en productos reales. El hecho de que AP2 invite a todos los actores "a construir este futuro con nosotros" subraya que la hoja de ruta se trata de colaboración. Si el impulso continúa, AP2 podría volverse tan común en unos años como lo son hoy protocolos como OAuth u OpenID Connect en sus dominios: una capa invisible pero crítica que permite la funcionalidad en todos los servicios.

Conclusión​

AP2 (Protocolo de Pagos de Agentes/Agentes) representa un paso significativo hacia un futuro donde los agentes de IA puedan realizar transacciones de manera tan confiable y segura como los humanos. Técnicamente, introduce un mecanismo inteligente de mandatos y credenciales verificables que infunden confianza en las transacciones dirigidas por agentes, asegurando que la intención del usuario sea explícita y aplicable. Su arquitectura abierta y extensible le permite integrarse tanto con los florecientes frameworks de agentes de IA como con la infraestructura financiera establecida. Al abordar las preocupaciones centrales de autorización, autenticidad y rendición de cuentas, AP2 sienta las bases para que el comercio impulsado por IA prospere sin sacrificar la seguridad ni el control del usuario.

La introducción de AP2 puede verse como el establecimiento de una nueva base – al igual que los primeros protocolos de internet habilitaron la web – para lo que algunos llaman la "economía de agentes". Abre el camino a innumerables innovaciones: agentes de compras personales, bots de búsqueda automática de ofertas, agentes autónomos de la cadena de suministro y más, todos operando bajo un marco de confianza común. Es importante destacar que el diseño inclusivo de AP2 (que abarca desde tarjetas de crédito hasta criptomonedas) lo posiciona en la intersección de las finanzas tradicionales y Web3, lo que podría unir estos mundos a través de un protocolo común mediado por agentes.

La respuesta de la industria hasta ahora ha sido muy positiva, con una amplia coalición que señala que AP2 probablemente se convertirá en un estándar ampliamente adoptado. El éxito de AP2 dependerá de la colaboración continua y las pruebas en el mundo real, pero sus perspectivas son sólidas dada la clara necesidad que aborda. En un sentido más amplio, AP2 ejemplifica cómo evoluciona la tecnología: surgió una nueva capacidad (agentes de IA) que rompió viejas suposiciones, y la solución fue desarrollar un nuevo estándar abierto para acomodar esa capacidad. Al invertir ahora en un protocolo abierto y centrado en la seguridad, Google y sus socios están construyendo efectivamente la arquitectura de confianza necesaria para la próxima era del comercio. Como dice el dicho, "la mejor manera de predecir el futuro es construirlo"; AP2 es una apuesta por un futuro en el que los agentes de IA gestionen transacciones por nosotros sin problemas, y está construyendo activamente la confianza y las reglas necesarias para que ese futuro sea viable.

Fuentes:

• Blog de Google Cloud – “Impulsando el comercio de IA con el nuevo Protocolo de Pagos de Agentes (AP2)” (16 de septiembre de 2025)
• Documentación de AP2 en GitHub – “Especificación y Resumen del Protocolo de Pagos de Agentes”
• Blog de Vellum AI – “AP2 de Google: Un nuevo protocolo para pagos de agentes de IA” (Análisis)
• Artículo de Medium – “Protocolo de Pagos de Agentes (AP2) de Google” (Resumen de Tahir, septiembre de 2025)
• Citas de Socios sobre AP2 (Blog de Google Cloud)
• Extensión A2A x402 (extensión de pagos criptográficos de AP2) – README de GitHub

La Cumbre de Aplicaciones Blockchain de Stanford (BASS) dio inicio a la semana de la Conferencia Ciencia de Blockchain (SBC), reuniendo a innovadores, investigadores y constructores para explorar la vanguardia del ecosistema. Los organizadores Gil, Kung y Stephen dieron la bienvenida a los asistentes, resaltando el enfoque del evento en el emprendimiento y las aplicaciones del mundo real, un espíritu nacido de su estrecha colaboración con SBC. Con el apoyo de organizaciones como Blockchain Builders y el Alumni de Criptografía y Blockchain de Stanford, el día estuvo repleto de inmersiones profundas en blockchains celestiales, el futuro de Ethereum, DeFi institucional y la creciente intersección de IA y cripto.

Dalia Maliki: Construyendo una Raíz Orbital de Confianza con Computadora Espacial​

Dalia Maliki, profesora en UC Santa Barbara y asesora de Space Computer, abrió con una mirada a una aplicación verdaderamente fuera de este mundo: construir una plataforma de cómputo segura en órbita.

¿Qué es Space Computer?
En pocas palabras, Space Computer es una “raíz orbital de confianza”, que brinda una plataforma para ejecutar cálculos seguros y confidenciales en satélites. La propuesta de valor central radica en las garantías de seguridad únicas del espacio. “Una vez que una caja se lanza de forma segura y se despliega en el espacio, nadie puede venir después y hackearla”, explicó Maliki. “Es puramente, perfectamente a prueba de manipulaciones en este punto”. Este entorno la hace a prueba de fugas, asegura que las comunicaciones no puedan ser interferidas fácilmente y proporciona geolocalización verificable, ofreciendo potentes propiedades de descentralización.

Arquitectura y Casos de Uso
El sistema está diseñado con una arquitectura de dos capas:

• Capa 1 (Celestial): La raíz de confianza autoritativa funciona en una red de satélites en órbita, optimizada para comunicaciones limitadas e intermitentes.
• Capa 2 (Terrestre): Soluciones de escalado estándar como rollups y canales de estado se ejecutan en la Tierra, anclándose a la Capa 1 celestial para obtener finalización y seguridad.

Los primeros casos de uso incluyen ejecutar validadores de blockchain altamente seguros y un generador de números aleatorios verdadero que captura radiación cósmica. Sin embargo, Maliki enfatizó el potencial de la plataforma para innovaciones imprevistas. “Lo más genial de construir una plataforma es que siempre construyes una plataforma y otras personas vienen y crean casos de uso que ni siquiera soñaste”.

Trazando un paralelismo con el ambicioso Proyecto Corona de los años 50, que dejaba caer cubos de película desde satélites espía para ser atrapados en el aire por aviones, Maliki instó a la audiencia a pensar en grande. “En comparación, lo que trabajamos hoy con la computadora espacial es un lujo, y estamos muy entusiasmados con el futuro”.

Tomasz Stanczak: La Hoja de Ruta de Ethereum – Escalado, Privacidad e IA​

Tomasz Stanczak, Director Ejecutivo de la Ethereum Foundation, ofreció una visión integral de la hoja de ruta evolutiva de Ethereum, centrada fuertemente en el escalado, la mejora de la privacidad y la integración con el mundo de la IA.

Enfoque a Corto Plazo: Soporte a L2s
La prioridad inmediata para Ethereum es consolidar su papel como la mejor plataforma para que las Layer 2 construyan sobre ella. Los próximos forks, Fusaka y Glumpsterdom, están centrados en este objetivo. “Queremos hacer declaraciones mucho más fuertes de que sí, las L2 innovan, extienden Ethereum y contarán con el compromiso de los constructores de protocolo de que la Layer 1 apoyará a las L2 de la mejor manera posible”, afirmó Stanczak.

Visión a Largo Plazo: Lean Ethereum y Pruebas en Tiempo Real
Mirando más adelante, la visión de “Lean Ethereum” apunta a una escalabilidad masiva y al endurecimiento de la seguridad. Un componente clave es la hoja de ruta ZK‑EVM, que persigue pruebas en tiempo real con latencias menores a 10 segundos para el 99 % de los bloques, alcanzables por stakers solos. Esto, combinado con mejoras en la disponibilidad de datos, podría impulsar a las L2 a un teórico “10 millones de TPS”. El plan a largo plazo también incluye un enfoque en criptografía post‑cuántica mediante firmas basadas en hash y ZK‑EVMs.

Privacidad e Intersección con IA
La privacidad es otro pilar crítico. La Ethereum Foundation ha creado el equipo Privacy and Scaling Explorations (PSC) para coordinar esfuerzos, apoyar herramientas y explorar integraciones de privacidad a nivel de protocolo. Stanczak ve esto como esencial para la interacción de Ethereum con la IA, habilitando casos de uso como mercados financieros resistentes a la censura, IA que preserva la privacidad y sistemas agentes de código abierto. Subrayó que la cultura de Ethereum de conectar múltiples disciplinas —desde finanzas y arte hasta robótica e IA— es fundamental para navegar los retos y oportunidades de la próxima década.

Sreeram Kannan: El Marco de Confianza para Apps Crypto Ambiciosas con EigenCloud​

Sreeram Kannan, fundador de Eigen Labs, desafió a la audiencia a pensar más allá del alcance actual de las aplicaciones crypto, presentando un marco para entender el valor central de crypto e introduciendo EigenCloud como la plataforma para materializar esta visión.

Tesis Central de Crypto: Una Capa de Verificabilidad
“Subyacente a todo esto hay una tesis central de que crypto es la capa de confianza o verificabilidad sobre la cual puedes construir aplicaciones muy poderosas”, explicó Kannan. Presentó un marco “TAM vs. Trust”, ilustrando que el mercado total direccionable (TAM) para una aplicación crypto crece exponencialmente a medida que la confianza que subyace aumenta. El mercado de Bitcoin crece al volverse más confiable que las monedas fiat; el mercado de una plataforma de préstamos crece al volverse más creíble su garantía de solvencia del prestatario.

EigenCloud: Liberando la Programabilidad
Kannan argumentó que el principal cuello de botella para construir apps más ambiciosas —como un Uber descentralizado o plataformas de IA confiables— no es el rendimiento sino la programabilidad. Para resolverlo, EigenCloud introduce una nueva arquitectura que separa la lógica de la aplicación de la lógica del token.

“Mantengamos la lógica del token on‑chain en Ethereum”, propuso, “pero la lógica de la aplicación se traslada fuera. Ahora puedes escribir tu lógica central en contenedores arbitrarios… ejecutarlos en cualquier dispositivo que elijas, sea CPU o GPU… y luego traer esos resultados de forma verificable de vuelta on‑chain”.

Este enfoque, según él, extiende crypto de una “escala de laptop o servidor a escala de nube”, permitiendo a los desarrolladores crear las aplicaciones verdaderamente disruptivas que se imaginaron en los primeros días de crypto.

Panel: Un Análisis Profundo de la Arquitectura Blockchain​

Un panel con Leiyang de MegaETH, Adi de Realo y Solomon de la Solana Foundation exploró los trade‑offs entre arquitecturas monolíticas, modulares y “super modulares”.

• MegaETH (L2 Modular): Leiyang describió el enfoque de MegaETH de usar un secuenciador centralizado para velocidad extrema mientras delega la seguridad a Ethereum. Este diseño busca ofrecer una experiencia en tiempo real al nivel de Web2 para aplicaciones, reviviendo las ambiciosas ideas de la era ICO que antes estaban limitadas por el rendimiento.
• Solana (L1 Monolítica): Solomon explicó que la arquitectura de Solana, con sus altos requisitos de nodos, está diseñada deliberadamente para el máximo rendimiento y apoyar su visión de poner toda la actividad financiera global on‑chain. El foco actual está en emisión de activos y pagos. Sobre interoperabilidad, Solomon fue franco: “En general, no nos importa mucho la interoperabilidad… Se trata de conseguir la mayor liquidez y uso de activos on‑chain posible”.
• Realo (L1 “Super Modular”): Adi presentó el concepto “super modular” de Realo, que consolida servicios esenciales como oráculos directamente en la capa base para reducir la fricción del desarrollador. Este diseño busca conectar nativamente la blockchain al mundo real, con un enfoque go‑to‑market en RWAs y haciendo que la blockchain sea invisible para los usuarios finales.

Panel: La Intersección Real de IA y Blockchain​

Moderado por Ed Roman de HackVC, este panel mostró tres enfoques distintos para fusionar IA y crypto.

• Ping AI (Bill): Ping AI está construyendo una “IA personal” donde los usuarios mantienen la auto‑custodia de sus datos. La visión es reemplazar el modelo tradicional de intercambio de anuncios. En lugar de que las empresas moneticen los datos de los usuarios, el sistema de Ping AI recompensará directamente a los usuarios cuando sus datos generen una conversión, permitiéndoles capturar el valor económico de su huella digital.
• Public AI (Jordan): Descrita como la “capa humana de la IA”, Public AI es un marketplace para obtener datos de alta calidad bajo demanda que no pueden ser raspados ni generados sintéticamente. Utiliza un sistema de reputación on‑chain y mecanismos de staking para asegurar que los contribuyentes aporten señal, no ruido, recompensándolos por su trabajo en la construcción de mejores modelos de IA.
• Gradient (Eric): Gradient está creando un runtime descentralizado para IA, habilitando inferencia y entrenamiento distribuidos en una red de hardware de consumo subutilizado. El objetivo es proporcionar un contrapeso al poder centralizador de las grandes compañías de IA al permitir que una comunidad global entrene y sirva modelos de forma colaborativa, manteniendo la “soberanía inteligente”.

Más Destacados de la Cumbre​

• Orin Katz (Starkware) presentó bloques de construcción para “privacidad on‑chain compliant”, detallando cómo los ZK‑proofs pueden usarse para crear pools de privacidad y tokens privados (ZRC20) que incluyen mecanismos como “claves de visualización” para supervisión regulatoria.
• Sam Green (Cambrian) ofreció una visión general del panorama “Agentic Finance”, categorizando agentes crypto en trading, provisión de liquidez, préstamos, predicción e información, y resaltó la necesidad de datos rápidos, integrales y verificables para alimentarlos.
• Max Siegel (Privy) compartió lecciones de la incorporación de más de 75 millones de usuarios, enfatizando la necesidad de encontrarse donde están los usuarios, simplificar experiencias de producto y dejar que las necesidades del producto guíen las decisiones de infraestructura, no al revés.
• Nil Dalal (Coinbase) introdujo el “Onchain Agentic Commerce Stack” y el estándar abierto X42, un protocolo nativo de crypto diseñado para crear una “web pagable por máquinas” donde agentes de IA puedan transaccionar sin problemas usando stablecoins para datos, APIs y servicios.
• Gordon Liao & Austin Adams (Circle) revelaron Circle Gateway, una nueva primitiva para crear un balance USDC unificado que está abstractado por cadena. Esto permite despliegues de liquidez casi instantáneos (< 500 ms) en múltiples cadenas, mejorando drásticamente la eficiencia de capital para empresas y solucionadores.

El día concluyó con un mensaje claro: las capas fundacionales de crypto están madurando, y el foco se está desplazando decisivamente hacia la construcción de aplicaciones robustas, amigables para el usuario y económicamente sostenibles que puedan cerrar la brecha entre el mundo on‑chain y la economía global.

Introducción​

Los mercados descentralizados de inferencia/entrenamiento de IA buscan aprovechar los recursos de cómputo globales y los modelos comunitarios de una manera sin confianza (trustless). Proyectos como Bittensor, Gensyn y Cuckoo Network (Cuckoo AI) ilustran cómo la tecnología blockchain puede potenciar mercados abiertos de IA. Cada plataforma tokeniza activos clave de IA —poder de cómputo, modelos de aprendizaje automático y, a veces, datos— en unidades económicas en la cadena. A continuación, profundizamos en las arquitecturas técnicas que sustentan estas redes, cómo tokenizan los recursos, sus estructuras de gobernanza e incentivos, los métodos para rastrear la propiedad de los modelos, los mecanismos de reparto de ingresos y las superficies de ataque (por ejemplo, ataques Sybil, colusión, parasitismo, envenenamiento) que surgen. Una tabla comparativa al final resume todas las dimensiones clave entre Bittensor, Gensyn y Cuckoo AI.

Arquitecturas Técnicas​

Bittensor: “Internet Neuronal” Descentralizado en Subredes​

Bittensor está construido sobre una blockchain de Capa 1 personalizada (la cadena Subtensor, basada en Substrate) que coordina una red de nodos de modelos de IA a través de muchas subredes especializadas. Cada subred es una minirred independiente que se enfoca en una tarea de IA particular (por ejemplo, una subred para la generación de lenguaje, otra para la generación de imágenes, etc.). Los participantes en Bittensor asumen roles distintos:

• Mineros – ejecutan modelos de aprendizaje automático en su hardware y proporcionan respuestas de inferencia (o incluso realizan entrenamiento) para la tarea de la subred. En esencia, un minero es un nodo que aloja un modelo de IA que responderá a las consultas.
• Validadores – consultan los modelos de los mineros con prompts y evalúan la calidad de las respuestas, formando una opinión sobre qué mineros están contribuyendo con resultados valiosos. Los validadores califican efectivamente el rendimiento de los mineros.
• Propietarios de Subred – crean y definen subredes, estableciendo las reglas sobre qué tareas se realizan y cómo se lleva a cabo la validación en esa subred. Un propietario de subred podría, por ejemplo, especificar que una subred es para un cierto conjunto de datos o modalidad y definir el procedimiento de validación.
• Delegadores – los poseedores de tokens que no ejecutan nodos pueden delegar (hacer stake) sus tokens de Bittensor (TAO) a mineros o validadores para respaldar a los de mejor rendimiento y ganar una parte de las recompensas (similar al staking en redes de prueba de participación).

El mecanismo de consenso de Bittensor es novedoso: en lugar de la validación de bloques tradicional, Bittensor utiliza el consenso Yuma, que es una forma de "prueba de inteligencia". En el consenso Yuma, las evaluaciones de los validadores sobre los mineros se agregan en la cadena para determinar la distribución de recompensas. Cada bloque de 12 segundos, la red acuña nuevos tokens TAO y los distribuye según el consenso de los validadores sobre qué mineros proporcionaron trabajo útil. Las puntuaciones de los validadores se combinan en un esquema de mediana ponderada por participación (stake): las opiniones atípicas se recortan y prevalece la opinión de la mayoría honesta. Esto significa que si la mayoría de los validadores están de acuerdo en que un minero fue de alta calidad, ese minero obtendrá una fuerte recompensa; si un validador se desvía mucho de los demás (posiblemente debido a colusión o error), ese validador es penalizado ganando menos. De esta manera, la blockchain de Bittensor coordina un bucle de retroalimentación minero-validador: los mineros compiten para producir los mejores resultados de IA, y los validadores curan y clasifican esos resultados, ganando ambas partes tokens proporcionales al valor que agregan. Esta arquitectura a menudo se describe como una "red neuronal descentralizada" o "cerebro global", donde los modelos aprenden de las señales de los demás y evolucionan colectivamente. Notablemente, Bittensor actualizó recientemente su cadena para admitir la compatibilidad con EVM (para contratos inteligentes) e introdujo dTAO, un sistema de tokens y staking específicos de subred (explicado más adelante) para descentralizar aún más el control de la asignación de recursos.

Gensyn: Protocolo de Cómputo Distribuido sin Confianza (Trustless)​

Gensyn aborda la IA descentralizada desde el ángulo de un protocolo de computación distribuida para el aprendizaje automático. Su arquitectura conecta a desarrolladores (solicitantes) que tienen tareas de IA (como entrenar un modelo o ejecutar un trabajo de inferencia) con proveedores de cómputo (resolutores) de todo el mundo que tienen recursos de GPU/TPU de sobra. Originalmente, Gensyn planeaba una cadena L1 en Substrate, pero giró hacia la construcción en Ethereum como un rollup para una mayor seguridad y liquidez. La red Gensyn es, por lo tanto, una Capa 2 de Ethereum (un rollup de Ethereum) que coordina la publicación de trabajos y los pagos, mientras que la computación ocurre fuera de la cadena en el hardware de los proveedores.

Una innovación central del diseño de Gensyn es su sistema de verificación para el trabajo fuera de la cadena. Gensyn utiliza una combinación de verificación optimista (pruebas de fraude) y técnicas criptográficas para garantizar que cuando un resolutor afirma haber ejecutado una tarea de entrenamiento/inferencia, el resultado sea correcto. En la práctica, el protocolo involucra múltiples roles de participantes:

• Solicitante – la parte que solicita un trabajo (por ejemplo, alguien que necesita entrenar un modelo). Pagan la tarifa de la red y proporcionan el modelo/datos o la especificación de la tarea.
• Resolutor – un nodo que puja y ejecuta la tarea de ML en su hardware. Entrenarán el modelo o ejecutarán la inferencia según lo solicitado, luego enviarán los resultados y una prueba de computación.
• Verificador/Desafiador – nodos que pueden auditar o verificar aleatoriamente el trabajo del resolutor. Gensyn implementa un esquema al estilo de Truebit donde, por defecto, el resultado de un resolutor se acepta, pero un verificador puede desafiarlo dentro de una ventana si sospecha una computación incorrecta. En un desafío, se utiliza una "búsqueda binaria" interactiva a través de los pasos de la computación (un protocolo de prueba de fraude) para señalar cualquier discrepancia. Esto permite que la cadena resuelva disputas realizando solo una parte crítica mínima de la computación en la cadena, en lugar de rehacer toda la costosa tarea.

Crucialmente, Gensyn está diseñado para evitar la redundancia masiva de los enfoques ingenuos. En lugar de tener muchos nodos repitiendo el mismo trabajo de ML (lo que destruiría los ahorros de costos), el enfoque de "prueba de aprendizaje" de Gensyn utiliza metadatos de entrenamiento para verificar que se ha progresado en el aprendizaje. Por ejemplo, un resolutor podría proporcionar hashes criptográficos o puntos de control de los pesos intermedios del modelo y una prueba sucinta de que estos progresaron de acuerdo con las actualizaciones de entrenamiento. Esta prueba probabilística de aprendizaje se puede verificar de manera mucho más económica que volver a ejecutar todo el entrenamiento, lo que permite una verificación sin confianza sin replicación completa. Solo si un verificador detecta una anomalía se activaría una computación más pesada en la cadena como último recurso. Este enfoque reduce drásticamente la sobrecarga en comparación con la verificación por fuerza bruta, haciendo que el entrenamiento de ML descentralizado sea más factible. La arquitectura de Gensyn, por lo tanto, enfatiza fuertemente el diseño de juegos criptoeconómicos: los resolutores depositan una participación o fianza, y si hacen trampa (enviando resultados incorrectos), pierden esa participación a favor de los verificadores honestos que los atrapan. Al combinar la coordinación de la blockchain (para pagos y resolución de disputas) con el cómputo fuera de la cadena y una verificación inteligente, Gensyn crea un mercado para el cómputo de ML que puede aprovechar las GPU inactivas en cualquier lugar mientras mantiene la falta de confianza. El resultado es un "protocolo de cómputo" a hiperescala donde cualquier desarrollador puede acceder a un poder de entrenamiento asequible y distribuido globalmente bajo demanda.

Cuckoo AI: Plataforma de Servicios de IA Descentralizada Full-Stack​

Cuckoo Network (o Cuckoo AI) adopta un enfoque más integrado verticalmente, con el objetivo de proporcionar servicios de IA descentralizados de extremo a extremo en lugar de solo cómputo en bruto. Cuckoo construyó su propia blockchain (inicialmente una Capa 1 llamada Cuckoo Chain en Arbitrum Orbit, un marco de rollup compatible con Ethereum) para orquestar todo: no solo empareja trabajos con GPU, sino que también aloja aplicaciones de IA y maneja pagos en un solo sistema. El diseño es full-stack: combina una blockchain para transacciones y gobernanza, una capa de recursos de GPU/CPU descentralizada y aplicaciones y API de IA orientadas al usuario en la parte superior. En otras palabras, Cuckoo integra las tres capas —blockchain, cómputo y aplicación de IA— dentro de una única plataforma.

Los participantes en Cuckoo se dividen en cuatro grupos:

• Constructores de Aplicaciones de IA (Coordinadores) – son desarrolladores que despliegan modelos o servicios de IA en Cuckoo. Por ejemplo, un desarrollador podría alojar un generador de imágenes Stable Diffusion o un chatbot LLM como servicio. Ejecutan Nodos Coordinadores, que son responsables de gestionar su servicio: aceptar solicitudes de usuarios, dividirlas en tareas y asignar esas tareas a los mineros. Los coordinadores hacen stake del token nativo ($CAI) para unirse a la red y obtener el derecho a utilizar mineros. Esencialmente, actúan como orquestadores de capa 2 que interactúan entre los usuarios y los proveedores de GPU.
• Mineros de GPU/CPU (Nodos de Tarea) – son los proveedores de recursos. Los mineros ejecutan el cliente de tareas de Cuckoo y contribuyen con su hardware para realizar tareas de inferencia para las aplicaciones de IA. Por ejemplo, a un minero se le podría asignar una solicitud de generación de imágenes (con un modelo y prompt dados) por parte de un coordinador y usar su GPU para calcular el resultado. Los mineros también deben hacer stake de $CAI para garantizar el compromiso y el buen comportamiento. Ganan recompensas en tokens por cada tarea que completan correctamente.
• Usuarios Finales – los consumidores de las aplicaciones de IA. Interactúan a través del portal web o las API de Cuckoo (por ejemplo, generando arte a través de CooVerse o chateando con personalidades de IA). Los usuarios pueden pagar con criptomonedas por cada uso o posiblemente contribuir con su propio cómputo (o stake) para compensar los costos de uso. Un aspecto importante es la resistencia a la censura: si un coordinador (proveedor de servicios) es bloqueado o se cae, los usuarios pueden cambiar a otro que sirva la misma aplicación, ya que múltiples coordinadores podrían alojar modelos similares en la red descentralizada.
• Stakers (Delegadores) – los miembros de la comunidad que no ejecutan servicios de IA o hardware de minería aún pueden participar haciendo stake de $CAI en aquellos que sí lo hacen. Al votar con su stake en coordinadores o mineros de confianza, ayudan a señalar la reputación y, a cambio, ganan una parte de las recompensas de la red. Este diseño construye una capa de reputación Web3: los buenos actores atraen más stake (y por lo tanto, confianza y recompensas), mientras que los malos actores pierden stake y reputación. Incluso los usuarios finales pueden hacer stake en algunos casos, alineándolos con el éxito de la red.

La cadena Cuckoo (ahora en proceso de transición de una cadena independiente a un rollup de seguridad compartida) rastrea todas estas interacciones. Cuando un usuario invoca un servicio de IA, el nodo coordinador crea asignaciones de tareas en la cadena para los mineros. Los mineros ejecutan las tareas fuera de la cadena y devuelven los resultados al coordinador, que los valida (por ejemplo, verificando que la imagen o el texto de salida no sean galimatías) y entrega el resultado final al usuario. La blockchain se encarga de la liquidación de pagos: por cada tarea, el contrato inteligente del coordinador paga al minero en $CAI (a menudo agregando micropagos en pagos diarios). Cuckoo enfatiza la falta de confianza y la transparencia – todos los participantes hacen stake de tokens y todas las asignaciones y finalizaciones de tareas se registran, por lo que se desalienta el engaño por la amenaza de perder el stake y por la visibilidad pública del rendimiento. El diseño modular de la red significa que se pueden agregar fácilmente nuevos modelos de IA o casos de uso: aunque comenzó con la generación de texto a imagen como prueba de concepto, su arquitectura es lo suficientemente general como para admitir otras cargas de trabajo de IA (por ejemplo, inferencia de modelos de lenguaje, transcripción de audio, etc.).

Un aspecto notable de la arquitectura de Cuckoo es que inicialmente lanzó su propia blockchain de Capa 1 para maximizar el rendimiento de las transacciones de IA (alcanzando un pico de 300k transacciones diarias durante las pruebas). Esto permitió optimizaciones personalizadas para la programación de tareas de IA. Sin embargo, el equipo encontró que mantener una L1 independiente era costoso y complejo, y a mediados de 2025 decidieron descontinuar la cadena personalizada y migrar a un modelo de rollup/AVS (Servicio Validado Activo) en Ethereum. Esto significa que Cuckoo heredará la seguridad de Ethereum o de una L2 como Arbitrum, en lugar de ejecutar su propio consenso, pero continuará operando su mercado de IA descentralizado en esa capa de seguridad compartida. El cambio tiene como objetivo mejorar la seguridad económica (aprovechando la robustez de Ethereum) y permitir que el equipo de Cuckoo se concentre en el producto en lugar del mantenimiento de la cadena de bajo nivel. En resumen, la arquitectura de Cuckoo crea una plataforma de servicio de IA descentralizada donde cualquiera puede conectar hardware o desplegar un servicio de modelo de IA, y los usuarios de todo el mundo pueden acceder a aplicaciones de IA con un costo menor y menos dependencia de la infraestructura de las grandes tecnológicas.

Mecanismos de Tokenización de Activos​

Un tema común en estas redes es la conversión de cómputo, modelos y datos en activos en la cadena o unidades económicas que pueden ser comercializadas o monetizadas. Sin embargo, cada proyecto se enfoca en tokenizar estos recursos de diferentes maneras:

• Poder de Cómputo: Las tres plataformas convierten el trabajo de cómputo en tokens de recompensa. En Bittensor, la computación útil (inferencia o entrenamiento realizado por un minero) se cuantifica a través de las puntuaciones de los validadores y se recompensa con tokens TAO en cada bloque. Esencialmente, Bittensor "mide" la inteligencia aportada y acuña TAO como una mercancía que representa esa contribución. Gensyn trata explícitamente el cómputo como una mercancía – su protocolo crea un mercado donde el tiempo de GPU es el producto, y el precio se establece por la oferta y la demanda en términos de tokens. Los desarrolladores compran cómputo usando el token, y los proveedores ganan tokens vendiendo los ciclos de su hardware. El equipo de Gensyn señala que cualquier recurso digital (cómputo, datos, algoritmos) puede ser representado y comercializado en un mercado sin confianza similar. Cuckoo tokeniza el cómputo a través de un token ERC-20 $CAI emitido como pago por tareas completadas. Los proveedores de GPU esencialmente "minan" CAI al realizar trabajos de inferencia de IA. El sistema de Cuckoo crea registros en la cadena de las tareas, por lo que se puede pensar en cada tarea de GPU completada como una unidad atómica de trabajo que se paga en tokens. La premisa en los tres es que el poder de cómputo, que de otro modo estaría inactivo o inaccesible, se convierte en un activo tokenizado y líquido, ya sea a través de emisiones de tokens a nivel de protocolo (como en Bittensor y el Cuckoo inicial) o a través de un mercado abierto de órdenes de compra/venta para trabajos de cómputo (como en Gensyn).

• Modelos de IA: Representar los modelos de IA como activos en la cadena (por ejemplo, NFT o tokens) todavía es incipiente. Bittensor no tokeniza los modelos en sí mismos; los modelos permanecen fuera de la cadena bajo la propiedad de los mineros. En cambio, Bittensor valora indirectamente los modelos al recompensar a los que tienen un buen rendimiento. En efecto, la "inteligencia" de un modelo se convierte en ganancias de TAO, pero no hay un NFT que represente los pesos del modelo o permita a otros usarlo. El enfoque de Gensyn está en las transacciones de cómputo, no explícitamente en la creación de tokens para modelos. Un modelo en Gensyn es típicamente proporcionado por un desarrollador fuera de la cadena (quizás de código abierto o propietario), entrenado por resolutores y devuelto; no hay un mecanismo incorporado para crear un token que posea el modelo o su propiedad intelectual. (Dicho esto, el mercado de Gensyn podría facilitar potencialmente el comercio de artefactos o puntos de control de modelos si las partes lo eligen, pero el protocolo en sí ve los modelos como el contenido de la computación en lugar de un activo tokenizado). Cuckoo se encuentra en un punto intermedio: habla de "agentes de IA" y modelos integrados en la red, pero actualmente no hay un token no fungible que represente cada modelo. En cambio, un modelo es desplegado por un constructor de aplicaciones y luego servido a través de la red. Los derechos de uso de ese modelo se tokenizan implícitamente en el sentido de que el modelo puede ganar $CAI cuando se utiliza (a través del coordinador que lo despliega). Las tres plataformas reconocen el concepto de tokenización de modelos —por ejemplo, dar a las comunidades la propiedad de los modelos a través de tokens— pero las implementaciones prácticas son limitadas. Como industria, la tokenización de modelos de IA (por ejemplo, como NFT con derechos de propiedad y participación en los beneficios) todavía se está explorando. El enfoque de Bittensor de que los modelos intercambien valor entre sí es una forma de "mercado de modelos" sin un token explícito por modelo. El equipo de Cuckoo señala que la propiedad descentralizada de modelos es prometedora para reducir las barreras frente a la IA centralizada, pero requiere métodos efectivos para verificar los resultados y el uso de los modelos en la cadena. En resumen, el poder de cómputo se tokeniza inmediatamente (es sencillo pagar tokens por el trabajo realizado), mientras que los modelos se tokenizan indirecta o aspiracionalmente (recompensados por sus resultados, posiblemente representados por stake o reputación, pero aún no tratados como NFT transferibles en estas plataformas).

• Datos: La tokenización de datos sigue siendo lo más difícil. Ninguno de los proyectos, Bittensor, Gensyn o Cuckoo, tiene mercados de datos en la cadena completamente generalizados e integrados (donde los conjuntos de datos se comercializan con derechos de uso exigibles). Los nodos de Bittensor pueden entrenar con varios conjuntos de datos, pero esos conjuntos de datos no forman parte del sistema en la cadena. Gensyn podría permitir que un desarrollador proporcione un conjunto de datos para el entrenamiento, pero el protocolo no tokeniza esos datos; simplemente se proporcionan fuera de la cadena para que el resolutor los use. Cuckoo tampoco tokeniza los datos del usuario; maneja principalmente los datos (como los prompts o resultados del usuario) de manera transitoria para las tareas de inferencia. El blog de Cuckoo declara explícitamente que "los datos descentralizados siguen siendo difíciles de tokenizar" a pesar de ser un recurso crítico. Los datos son sensibles (problemas de privacidad y propiedad) y difíciles de manejar con la tecnología blockchain actual. Por lo tanto, mientras que el cómputo se está mercantilizando y los modelos comienzan a serlo, los datos permanecen en gran medida fuera de la cadena, excepto en casos especiales (algunos proyectos fuera de estos tres están experimentando con uniones de datos y recompensas en tokens por contribuciones de datos, pero eso está fuera de nuestro alcance actual). En resumen, el poder de cómputo es ahora una mercancía en la cadena en estas redes, los modelos se valoran a través de tokens pero aún no se tokenizan individualmente como activos, y la tokenización de datos sigue siendo un problema abierto (más allá de reconocer su importancia).

Gobernanza e Incentivos​

Un diseño robusto de gobernanza e incentivos es crucial para que estas redes de IA descentralizadas funcionen de manera autónoma y justa. Aquí examinamos cómo cada plataforma se gobierna a sí misma (quién toma las decisiones, cómo ocurren las actualizaciones o los cambios de parámetros) y cómo alinean los incentivos de los participantes a través de la economía de tokens.

• Gobernanza de Bittensor: En sus primeras etapas, el desarrollo y los parámetros de las subredes de Bittensor estaban en gran medida controlados por el equipo central y un conjunto de 64 validadores "raíz" en la subred principal. Esto era un punto de centralización: unos pocos validadores poderosos tenían una influencia desproporcionada en la asignación de recompensas, lo que llevó a lo que algunos llamaron un "sistema de votación oligárquico". Para abordar esto, Bittensor introdujo la gobernanza dTAO (TAO descentralizado) en 2025. El sistema dTAO cambió la asignación de recursos para que fuera impulsada por el mercado y controlada por la comunidad. Concretamente, los poseedores de TAO pueden hacer stake de sus tokens en pools de liquidez específicos de subred (esencialmente, "votan" sobre qué subredes deberían obtener más emisiones de la red) y reciben tokens alfa que representan la propiedad en esos pools de subred. Las subredes que atraen más stake tendrán un precio de token alfa más alto y obtendrán una mayor parte de la emisión diaria de TAO, mientras que las subredes impopulares o de bajo rendimiento verán cómo el capital (y por lo tanto las emisiones) se aleja. Esto crea un bucle de retroalimentación: si una subred produce servicios de IA valiosos, más personas hacen stake de TAO en ella (buscando recompensas), lo que le da a esa subred más TAO para recompensar a sus participantes, fomentando el crecimiento. Si una subred se estanca, los stakers se retiran a subredes más lucrativas. En efecto, los poseedores de TAO gobiernan colectivamente el enfoque de la red al señalar financieramente qué dominios de IA merecen más recursos. Esta es una forma de gobernanza en la cadena por peso de token, alineada con los resultados económicos. Aparte de la asignación de recursos, las principales actualizaciones del protocolo o los cambios de parámetros probablemente todavía pasan por propuestas de gobernanza donde los poseedores de TAO votan (Bittensor tiene un mecanismo para propuestas y referendos en la cadena gestionados por la Fundación Bittensor y un consejo electo, similar a la gobernanza de Polkadot). Con el tiempo, se puede esperar que la gobernanza de Bittensor se vuelva cada vez más descentralizada, con la fundación dando un paso atrás a medida que la comunidad (a través del stake de TAO) dirige cosas como la tasa de inflación, la aprobación de nuevas subredes, etc. La transición a dTAO es un gran paso en esa dirección, reemplazando a los tomadores de decisiones centralizados con un mercado de partes interesadas de tokens alineado con incentivos.

• Incentivos de Bittensor: La estructura de incentivos de Bittensor está estrechamente entrelazada con su consenso. Cada bloque (12 segundos), se acuña exactamente 1 TAO nuevo y se divide entre los contribuyentes de cada subred según el rendimiento. La división predeterminada para la recompensa de bloque de cada subred es 41 % para los mineros, 41 % para los validadores y 18 % para el propietario de la subred. Esto asegura que todos los roles sean recompensados: los mineros ganan por hacer el trabajo de inferencia, los validadores ganan por su esfuerzo de evaluación, y los propietarios de subredes (que pueden haber iniciado los datos/tarea para esa subred) ganan un residual por proporcionar el "mercado" o el diseño de la tarea. Esos porcentajes están fijados en el protocolo y tienen como objetivo alinear los incentivos de todos hacia una producción de IA de alta calidad. El mecanismo de consenso Yuma refina aún más los incentivos al ponderar las recompensas según las puntuaciones de calidad: un minero que proporciona mejores respuestas (según el consenso de los validadores) obtiene una porción mayor de ese 41 %, y un validador que sigue de cerca el consenso honesto obtiene más de la porción del validador. Los de bajo rendimiento son eliminados económicamente. Además, los delegadores (stakers) que respaldan a un minero o validador generalmente recibirán una parte de las ganancias de ese nodo (los nodos a menudo establecen una comisión y dan el resto a sus delegadores, similar al staking en redes PoS). Esto permite a los poseedores pasivos de TAO apoyar a los mejores contribuyentes y obtener rendimiento, reforzando aún más la meritocracia. El token de Bittensor (TAO) es, por lo tanto, un token de utilidad: se requiere para el registro de nuevos mineros (los mineros deben gastar una pequeña cantidad de TAO para unirse, lo que combate el spam Sybil) y se puede hacer stake para aumentar la influencia o ganar a través de la delegación. También se prevé como un token de pago si los usuarios externos quieren consumir servicios de la red de Bittensor (por ejemplo, pagando TAO para consultar un modelo de lenguaje en Bittensor), aunque el mecanismo de recompensa interno ha sido la "economía" principal hasta ahora. La filosofía general de incentivos es recompensar la "inteligencia valiosa" —es decir, modelos que ayudan a producir buenos resultados de IA— y crear una competencia que mejore continuamente la calidad de los modelos en la red.

• Gobernanza de Gensyn: El modelo de gobernanza de Gensyn está estructurado para evolucionar desde el control del equipo central al control de la comunidad a medida que la red madura. Inicialmente, Gensyn tendrá una Fundación Gensyn y un consejo electo que supervisarán las actualizaciones del protocolo y las decisiones del tesoro. Se espera que este consejo esté compuesto por miembros del equipo central y líderes comunitarios tempranos al principio. Gensyn planea un Evento de Generación de Tokens (TGE) para su token nativo (a menudo referido como GENS), después del cual el poder de gobernanza estaría cada vez más en manos de los poseedores de tokens a través de la votación en la cadena. El papel de la fundación es representar los intereses del protocolo y asegurar una transición suave hacia la descentralización total. En la práctica, Gensyn probablemente tendrá mecanismos de propuesta en la cadena donde los cambios en los parámetros (por ejemplo, la duración del juego de verificación, las tasas de comisión) o las actualizaciones se votan por la comunidad. Debido a que Gensyn se está implementando como un rollup de Ethereum, la gobernanza también podría vincularse a la seguridad de Ethereum (por ejemplo, usando claves de actualización para el contrato del rollup que eventualmente se entregan a una DAO de poseedores de tokens). La sección de descentralización y gobernanza del litepaper de Gensyn enfatiza que el protocolo debe ser en última instancia de propiedad global, alineándose con el ethos de que la "red para la inteligencia de máquinas" debería pertenecer a sus usuarios y contribuyentes. En resumen, la gobernanza de Gensyn comienza semi-centralizada pero está diseñada para convertirse en una DAO donde los poseedores de tokens GENS (potencialmente ponderados por stake o participación) toman decisiones colectivamente.

• Incentivos de Gensyn: Los incentivos económicos en Gensyn son dinámicas de mercado sencillas complementadas con seguridad criptoeconómica. Los desarrolladores (clientes) pagan por las tareas de ML en el token de Gensyn, y los Resolutores ganan tokens al completar esas tareas correctamente. El precio de los ciclos de cómputo se determina en un mercado abierto; presumiblemente, los desarrolladores pueden publicar tareas con una recompensa y los resolutores pueden pujar o simplemente tomarla si el precio cumple con sus expectativas. Esto asegura que mientras haya oferta de GPU inactivas, la competencia reducirá el costo a una tasa justa (el equipo de Gensyn proyecta una reducción de costos de hasta el 80 % en comparación con los precios de la nube, ya que la red encuentra el hardware disponible más barato a nivel mundial). Por otro lado, los resolutores tienen el incentivo de ganar tokens por su trabajo; su hardware que de otro modo estaría inactivo ahora genera ingresos. Para garantizar la calidad, Gensyn requiere que los resolutores hagan stake de una garantía cuando aceptan un trabajo: si hacen trampa o producen un resultado incorrecto y son atrapados, pierden esa garantía (puede ser recortada y otorgada al verificador honesto). Los verificadores son incentivados por la posibilidad de ganar una recompensa "jackpot" si atrapan a un resolutor fraudulento, similar al diseño de Truebit de recompensar periódicamente a los verificadores que identifican con éxito una computación incorrecta. Esto mantiene a los resolutores honestos y motiva a algunos nodos a actuar como vigilantes. En un escenario óptimo (sin trampas), los resolutores simplemente ganan la tarifa de la tarea y el rol de verificador está mayormente inactivo (o uno de los resolutores participantes podría actuar también como verificador de otros). El token de Gensyn sirve así tanto como moneda de gas para comprar cómputo como garantía de stake que asegura el protocolo. El litepaper menciona una testnet con tokens no permanentes y que los participantes tempranos de la testnet serán recompensados en el TGE con tokens reales. Esto indica que Gensyn asignó parte del suministro de tokens para el arranque —recompensando a los primeros adoptantes, resolutores de prueba y miembros de la comunidad. A largo plazo, las tarifas de los trabajos reales deberían sostener la red. También puede haber una pequeña tarifa de protocolo (un porcentaje de cada pago de tarea) que va a un tesoro o se quema; este detalle aún no está confirmado, pero muchos protocolos de mercado incluyen una tarifa para financiar el desarrollo o la recompra y quema de tokens. En resumen, los incentivos de Gensyn se alinean en torno a la finalización honesta de los trabajos de ML: haz el trabajo, te pagan; intenta hacer trampa, pierdes el stake; verifica a otros, ganas si atrapas a los tramposos. Esto crea un sistema económico de autovigilancia destinado a lograr una computación distribuida confiable.

• Gobernanza de Cuckoo: Cuckoo Network incorporó la gobernanza en su ecosistema desde el primer día, aunque todavía está en fase de desarrollo. El token $CAI es explícitamente un token de gobernanza además de sus roles de utilidad. La filosofía de Cuckoo es que los operadores de nodos de GPU, los desarrolladores de aplicaciones e incluso los usuarios finales deberían tener voz en la evolución de la red, lo que refleja su visión impulsada por la comunidad. En la práctica, las decisiones importantes (como actualizaciones del protocolo o cambios económicos) se decidirían mediante votos ponderados por tokens, presumiblemente a través de un mecanismo de DAO. Por ejemplo, Cuckoo podría realizar votaciones en la cadena para cambiar la distribución de recompensas o adoptar una nueva característica, y los poseedores de$CAI (incluidos mineros, desarrolladores y usuarios) votarían. La votación en la cadena ya se utiliza como un sistema de reputación: Cuckoo requiere que cada rol haga stake de tokens, y luego los miembros de la comunidad pueden votar (quizás delegando stake o a través de módulos de gobernanza) sobre qué coordinadores o mineros son de confianza. Esto afecta las puntuaciones de reputación y podría influir en la programación de tareas (por ejemplo, un coordinador con más votos podría atraer a más usuarios, o un minero con más votos podría recibir más tareas). Es una mezcla de gobernanza e incentivo: usar tokens de gobernanza para establecer la confianza. La Fundación Cuckoo o el equipo central ha guiado la dirección del proyecto hasta ahora (por ejemplo, tomando la reciente decisión de descontinuar la cadena L1), pero su blog indica un compromiso de avanzar hacia la propiedad descentralizada. Identificaron que operar su propia cadena incurría en altos costos generales y que pivotar hacia un rollup permitirá un desarrollo más abierto y la integración con los ecosistemas existentes. Es probable que una vez en una capa compartida (como Ethereum), Cuckoo implemente una DAO más tradicional para las actualizaciones, con la comunidad votando usando CAI.

• Incentivos de Cuckoo: El diseño de incentivos para Cuckoo tiene dos fases: la fase inicial de arranque con asignaciones de tokens fijas, y un estado futuro con reparto de ingresos impulsado por el uso. En su lanzamiento, Cuckoo realizó una distribución de "lanzamiento justo" de 1 mil millones de tokens CAI. El 51 % del suministro se reservó para la comunidad, asignado como:

• Recompensas de Minería: 30 % del suministro total reservado para pagar a los mineros de GPU por realizar tareas de IA.

• Recompensas de Staking: 11 % del suministro para aquellos que hacen stake y ayudan a asegurar la red.

• Airdrops: 5 % para los primeros usuarios y miembros de la comunidad como incentivo de adopción.

• (Otro 5 % fue para subvenciones a desarrolladores para fomentar la construcción en Cuckoo).

Esta gran asignación significa que en la red inicial, los mineros y stakers fueron recompensados de un pool de emisiones, incluso si la demanda real de los usuarios era baja. De hecho, la fase inicial de Cuckoo presentó altos rendimientos APY para el staking y la minería, lo que atrajo con éxito a los participantes, pero también a los "yield farmers" que solo estaban allí por los tokens. El equipo notó que muchos usuarios se fueron una vez que las tasas de recompensa cayeron, lo que indica que esos incentivos no estaban ligados a un uso genuino. Habiendo aprendido de esto, Cuckoo está cambiando a un modelo donde las recompensas se correlacionan directamente con la carga de trabajo real de IA. En el futuro (y parcialmente ya), cuando un usuario final paga por una inferencia de IA, ese pago (en CAI o posiblemente otro token aceptado convertido a CAI) se dividirá entre los contribuyentes:

• Los mineros de GPU recibirán la mayor parte por el cómputo que proporcionaron.
• El Coordinador (desarrollador de la aplicación) tomará una porción como el proveedor de servicios que suministró el modelo y manejó la solicitud.
• Los Stakers que han delegado a esos mineros o coordinadores podrían obtener una pequeña parte o una recompensa inflacionaria, para continuar incentivando el respaldo de nodos confiables.
• La Red/Tesorería podría retener una tarifa para el desarrollo continuo o para financiar futuros incentivos (o la tarifa podría ser cero/nominal para maximizar la asequibilidad para el usuario).

Esencialmente, Cuckoo se está moviendo hacia un modelo de reparto de ingresos: si una aplicación de IA en Cuckoo genera ganancias, esas ganancias se distribuyen a todos los contribuyentes de ese servicio de manera justa. Esto alinea los incentivos para que los participantes se beneficien del uso real en lugar de solo de la inflación. La red ya requería que todas las partes hicieran stake de CAI; esto significa que los mineros y coordinadores no solo ganan una recompensa plana, sino también posiblemente recompensas basadas en el stake (por ejemplo, un coordinador podría ganar mayores recompensas si muchos usuarios hacen stake en ellos o si ellos mismos hacen más stake, similar a cómo ganan los validadores de prueba de participación). En cuanto a los incentivos para los usuarios, Cuckoo también introdujo cosas como un portal de airdrops y faucets (que algunos usuarios explotaron) para sembrar la actividad inicial. En el futuro, los usuarios podrían ser incentivados a través de reembolsos en tokens por usar los servicios o a través de recompensas de gobernanza por participar en la curación (por ejemplo, quizás ganando pequeños tokens por calificar resultados o contribuir con datos). La conclusión es que el token de Cuckoo ($CAI) es multipropósito: es el token de gas/tarifa en la cadena (todas las transacciones y pagos lo usan), se usa para staking y votación, y es la unidad de recompensa por el trabajo realizado. Cuckoo menciona explícitamente que quiere vincular las recompensas de tokens a KPIs a nivel de servicio (indicadores clave de rendimiento) —por ejemplo, tiempo de actividad, rendimiento de consultas, satisfacción del usuario— para evitar incentivos puramente especulativos. Esto refleja una maduración de la economía de tokens desde la simple minería de liquidez a un modelo más sostenible e impulsado por la utilidad.

Propiedad de Modelos y Atribución de PI​

Manejar la propiedad intelectual (PI) y los derechos de propiedad de los modelos de IA es un aspecto complejo de las redes de IA descentralizadas. Cada plataforma ha adoptado una postura ligeramente diferente, y en general esta es un área en evolución sin una solución completa todavía:

• Bittensor: Los modelos en Bittensor son proporcionados por los nodos mineros, y esos mineros retienen el control total sobre los pesos de sus modelos (que nunca se publican en la cadena). Bittensor no rastrea explícitamente quién "posee" un modelo más allá del hecho de que se está ejecutando en una cierta dirección de billetera. Si un minero se va, su modelo se va con él. Por lo tanto, la atribución de PI en Bittensor es fuera de la cadena: si un minero usa un modelo propietario, no hay nada en la cadena que lo haga cumplir o incluso lo sepa. La filosofía de Bittensor fomenta las contribuciones abiertas (muchos mineros podrían usar modelos de código abierto como GPT-J u otros) y la red recompensa el rendimiento de esos modelos. Se podría decir que Bittensor crea una puntuación de reputación para los modelos (a través de las clasificaciones de los validadores), y esa es una forma de reconocer el valor del modelo, pero los derechos sobre el modelo en sí no están tokenizados ni distribuidos. Notablemente, los propietarios de subred en Bittensor podrían ser vistos como dueños de una pieza de PI: definen una tarea (que podría incluir un conjunto de datos o un método). El propietario de la subred acuña un NFT (llamado UID de subred) al crear una subred, y ese NFT les da derecho al 18 % de las recompensas en esa subred. Esto tokeniza efectivamente la creación de un mercado de modelos (la subred), si no las instancias del modelo. Si se considera la definición de la subred (digamos una tarea de reconocimiento de voz con un conjunto de datos particular) como PI, eso al menos se registra y recompensa. Pero los pesos individuales del modelo que los mineros entrenan, no hay un registro de propiedad en la cadena de ellos. La atribución viene en forma de recompensas pagadas a la dirección de ese minero. Bittensor actualmente no implementa un sistema donde, por ejemplo, varias personas puedan poseer conjuntamente un modelo y obtener un reparto automático de ingresos; la persona que ejecuta el modelo (minero) obtiene la recompensa y depende de ellos fuera de la cadena honrar cualquier licencia de PI del modelo que usaron.

• Gensyn: En Gensyn, la propiedad del modelo es sencilla en el sentido de que el solicitante (el que quiere que se entrene un modelo) proporciona la arquitectura del modelo y los datos, y después del entrenamiento, recibe el artefacto del modelo resultante. Los resolutores que realizan el trabajo no tienen derechos sobre el modelo; son como contratistas que reciben un pago por un servicio. El protocolo de Gensyn asume así el modelo de PI tradicional: si tenías derechos legales sobre el modelo y los datos que enviaste, todavía los tienes después de que se entrene; la red de cómputo no reclama ninguna propiedad. Gensyn menciona que el mercado también podría comerciar algoritmos y datos como cualquier otro recurso. Esto sugiere un escenario en el que alguien podría ofrecer un modelo o algoritmo para su uso en la red, posiblemente por una tarifa, tokenizando así el acceso a ese modelo. Por ejemplo, un creador de modelos podría poner su modelo preentrenado en Gensyn y permitir que otros lo ajusten a través de la red por una tarifa (esto monetizaría efectivamente la PI del modelo). Si bien el protocolo no hace cumplir los términos de la licencia, se podrían codificar los requisitos de pago: un contrato inteligente podría requerir una tarifa para desbloquear los pesos del modelo para un resolutor. Sin embargo, estos son casos de uso especulativos; el diseño principal de Gensyn se trata de habilitar trabajos de entrenamiento. En cuanto a la atribución, si varias partes contribuyen a un modelo (digamos que una proporciona datos, otra proporciona cómputo), eso probablemente se manejaría mediante cualquier contrato o acuerdo que establezcan antes de usar Gensyn (por ejemplo, un contrato inteligente podría dividir el pago entre el proveedor de datos y el proveedor de cómputo). Gensyn en sí no rastrea "este modelo fue construido por X, Y, Z" en la cadena más allá del registro de qué direcciones se pagaron por el trabajo. En resumen, la PI del modelo en Gensyn permanece con el solicitante, y cualquier atribución o licencia debe manejarse a través de los acuerdos legales fuera del protocolo o a través de contratos inteligentes personalizados construidos sobre él.

• Cuckoo: En el ecosistema de Cuckoo, los creadores de modelos (constructores de aplicaciones de IA) son participantes de primera clase: ellos despliegan el servicio de IA. Si un constructor de aplicaciones ajusta un modelo de lenguaje o desarrolla un modelo personalizado y lo aloja en Cuckoo, ese modelo es esencialmente su propiedad y actúan como el propietario del servicio. Cuckoo no se apropia de ninguna propiedad; en cambio, proporciona la infraestructura para que moneticen su uso. Por ejemplo, si un desarrollador despliega una IA de chatbot, los usuarios pueden interactuar con ella y el desarrollador (más los mineros) ganan CAI por cada interacción. La plataforma atribuye así los ingresos por uso al creador del modelo, pero no publica explícitamente los pesos del modelo ni los convierte en un NFT. De hecho, para ejecutar el modelo en las GPU de los mineros, el nodo coordinador probablemente tenga que enviar el modelo (o el tiempo de ejecución) al minero de alguna forma. Esto plantea preguntas sobre la PI: ¿podría un minero malicioso copiar los pesos del modelo y distribuirlos? En una red descentralizada, ese riesgo existe si se utilizan modelos propietarios. El enfoque actual de Cuckoo ha sido en modelos bastante abiertos (Stable Diffusion, modelos derivados de LLaMA, etc.) y en construir una comunidad, por lo que aún no hemos visto una aplicación de los derechos de PI a través de contratos inteligentes. La plataforma podría integrar potencialmente herramientas como la ejecución de modelos encriptados o enclaves seguros en el futuro para la protección de la PI, pero no se menciona nada específico en la documentación. Lo que sí rastrea es quién proporcionó el servicio del modelo para cada tarea: dado que el coordinador es una identidad en la cadena, todo el uso de su modelo se le atribuye, y obtienen automáticamente su parte de las recompensas. Si alguien entregara o vendiera un modelo a otra persona, efectivamente transferiría el control del nodo coordinador (quizás incluso simplemente dándoles la clave privada o el NFT si el rol de coordinador estuviera tokenizado). En la actualidad, la propiedad comunitaria de modelos (a través de participaciones en tokens) no está implementada, pero la visión de Cuckoo sugiere una IA descentralizada impulsada por la comunidad, por lo que podrían explorar permitir que las personas financien o gobiernen colectivamente un modelo de IA. La tokenización de modelos más allá de la propiedad individual sigue siendo un área abierta en estas redes; se reconoce como un objetivo (permitir que las comunidades posean modelos de IA en lugar de las corporaciones), pero en la práctica requiere soluciones para los desafíos de PI y verificación mencionados anteriormente.

En resumen, la propiedad de los modelos en Bittensor, Gensyn y Cuckoo se maneja fuera de la cadena por medios tradicionales: la persona o entidad que ejecuta o envía el modelo es efectivamente el propietario. Las redes proporcionan atribución en forma de recompensas económicas (pagando al contribuyente del modelo por su PI o esfuerzo). Ninguno de los tres tiene una licencia incorporada o una aplicación de regalías sobre el uso del modelo a nivel de contrato inteligente todavía. La atribución proviene de la reputación y la recompensa: por ejemplo, los mejores modelos de Bittensor obtienen altas puntuaciones de reputación (que es un registro público) y más TAO, lo que es un crédito implícito para sus creadores. Con el tiempo, podemos ver características como pesos de modelo vinculados a NFT o licencias descentralizadas para rastrear mejor la PI, pero actualmente la prioridad ha sido hacer que las redes funcionen e incentiven las contribuciones. Todos están de acuerdo en que verificar la procedencia y los resultados de los modelos es clave para permitir verdaderos mercados de activos de modelos, y la investigación en esta dirección está en curso.

Estructuras de Reparto de Ingresos​

Las tres plataformas deben decidir cómo dividir el pastel económico cuando varias partes colaboran para producir un resultado de IA valioso. ¿Quién recibe el pago y cuánto, cuando se utiliza un servicio de IA o cuando se emiten tokens? Cada una tiene un modelo de reparto de ingresos distinto:

• Bittensor: Como se mencionó en la sección de incentivos, la distribución de ingresos de Bittensor está definida por el protocolo a nivel de bloque: 41 % para los mineros, 41 % para los validadores, 18 % para el propietario de la subred por cada emisión de TAO del bloque. Esto es efectivamente un reparto de ingresos incorporado para el valor generado en cada subred. La parte del propietario de la subred (18 %) actúa como una regalía por el "diseño del modelo/tarea" o por iniciar el ecosistema de esa subred. El hecho de que mineros y validadores obtengan partes iguales asegura que sin validación, los mineros no son recompensados (y viceversa); son simbióticos y cada uno obtiene una porción igual de las recompensas acuñadas. Si consideramos a un usuario externo que paga TAO para consultar un modelo, el whitepaper de Bittensor prevé que ese pago también se divida de manera similar entre el minero que responde y los validadores que ayudaron a verificar la respuesta (la división exacta podría ser determinada por el protocolo o las fuerzas del mercado). Además, los delegadores que hacen stake en mineros/validadores son efectivamente socios; típicicamente, un minero/validador compartirá un porcentaje de su TAO ganado con sus delegadores (esto es configurable, pero a menudo la mayoría va a los delegadores). Así, si un minero ganó 1 TAO de un bloque, eso podría dividirse 80/20 entre sus delegadores y ellos mismos, por ejemplo, según el stake. Esto significa que incluso los no operadores obtienen una parte de los ingresos de la red proporcional a su apoyo. Con la introducción de dTAO, se agregó otra capa de reparto: aquellos que hacen stake en el pool de una subred obtienen tokens alfa, que les dan derecho a parte de las emisiones de esa subred (como el yield farming). En efecto, cualquiera puede tomar una participación en el éxito de una subred particular y recibir una fracción de las recompensas de mineros/validadores al poseer tokens alfa (los tokens alfa se aprecian a medida que la subred atrae más uso y emisiones). En resumen, el reparto de ingresos de Bittensor está fijado por código para los roles principales, y se comparte aún más mediante acuerdos sociales/de staking. Es una división relativamente transparente y basada en reglas: cada bloque, los participantes saben exactamente cómo se asigna el 1 TAO, y por lo tanto conocen sus "ganancias" por contribución. Esta claridad es una de las razones por las que Bittensor a veces se compara con Bitcoin para la IA: una emisión monetaria determinista donde la recompensa de los participantes se establece matemáticamente.

• Gensyn: El reparto de ingresos en Gensyn es más dinámico e impulsado por el mercado, ya que las tareas tienen un precio individual. Cuando un solicitante crea un trabajo, adjunta una recompensa (digamos X tokens) que está dispuesto a pagar. Un resolutor que completa el trabajo obtiene esa X (menos cualquier tarifa de red). Si un verificador está involucrado, típicamente hay una regla como: si no se detecta fraude, el resolutor se queda con el pago completo; si se detecta fraude, el resolutor es penalizado con slashing —perdiendo parte o la totalidad de su stake— y esa cantidad recortada se le da al verificador como recompensa. Así que los verificadores no ganan de cada tarea, solo cuando atrapan un mal resultado (además de posiblemente una pequeña tarifa base por participar, dependiendo de la implementación). No hay un concepto incorporado de pagar al propietario de un modelo aquí porque se asume que el solicitante es el propietario del modelo o tiene derechos para usarlo. Uno podría imaginar un escenario donde un solicitante está ajustando el modelo preentrenado de otra persona y una porción del pago va al creador original del modelo, pero eso tendría que manejarse fuera del protocolo (por ejemplo, mediante un acuerdo o un contrato inteligente separado que divida el pago del token en consecuencia). El reparto a nivel de protocolo de Gensyn es esencialmente cliente -> resolutor (-> verificador). El modelo de token probablemente incluye alguna asignación para el tesoro o la fundación del protocolo; por ejemplo, un pequeño porcentaje del pago de cada tarea podría ir a una tesorería que podría usarse para financiar el desarrollo o pools de seguros (esto no se indica explícitamente en los documentos disponibles, pero muchos protocolos lo hacen). Además, al principio, Gensyn puede subsidiar a los resolutores a través de la inflación: a los usuarios de la testnet se les prometen recompensas en el TGE, lo que es efectivamente un reparto de ingresos de la distribución inicial de tokens (los primeros resolutores y partidarios obtienen una parte de los tokens por ayudar a arrancar, similar a un airdrop o recompensa de minería). Con el tiempo, a medida que los trabajos reales dominen, las recompensas inflacionarias disminuirían, y los ingresos de los resolutores provendrían principalmente de los pagos de los usuarios. El enfoque de Gensyn se puede resumir como un modelo de ingresos de pago por servicio: la red facilita un pago directo de aquellos que necesitan que se haga un trabajo a aquellos que lo hacen, con los verificadores y posiblemente los stakers de tokens tomando una parte solo cuando desempeñan un papel en la seguridad de ese servicio.

• Cuckoo: El reparto de ingresos de Cuckoo ha evolucionado. Inicialmente, debido a que no había muchos usuarios finales que pagaran, el reparto de ingresos era esencialmente un reparto de inflación: las asignaciones del 30 % para minería y del 11 % para staking del suministro de tokens significaban que los mineros y stakers compartían los tokens emitidos por el pool de lanzamiento justo de la red. En la práctica, Cuckoo realizaba cosas como pagos diarios de CAI a los mineros proporcionales a las tareas completadas. Esos pagos provenían en gran medida de la asignación de recompensas de minería (que es parte del suministro fijo reservado). Esto es similar a cómo muchas blockchains de Capa 1 distribuyen recompensas de bloque a mineros/validadores; no estaba ligado al uso real por parte de usuarios externos, era más para incentivar la participación y el crecimiento. Sin embargo, como se destaca en su blog de julio de 2025, esto llevó a un uso incentivado por el farming de tokens en lugar de la demanda real. La siguiente etapa para Cuckoo es un verdadero modelo de reparto de ingresos basado en tarifas de servicio. En este modelo, cuando un usuario final usa, digamos, el servicio de generación de imágenes y paga $1 (en términos de cripto), ese valor de$1 en tokens se dividiría quizás así: 0.70 para el minero que hizo el trabajo de GPU, 0.20 para el desarrollador de la aplicación (coordinador) que proporcionó el modelo y la interfaz, y 0.10 para los stakers o la tesorería de la red. (Nota: las proporciones exactas son hipotéticas; Cuckoo no las ha especificado públicamente todavía, pero esto ilustra el concepto). De esta manera, todos los contribuyentes a la prestación del servicio obtienen una parte de los ingresos. Esto es análogo, por ejemplo, a una economía de viajes compartidos pero para la IA: el vehículo (minero de GPU) obtiene la mayoría, el conductor o la plataforma (coordinador que construyó el servicio del modelo) obtiene una parte, y quizás la gobernanza/stakers de la plataforma obtienen una pequeña tarifa. La mención de Cuckoo de "modelos de reparto de ingresos y recompensas de tokens vinculados directamente a métricas de uso" sugiere que si un servicio o nodo en particular maneja mucho volumen, sus operadores y partidarios ganarán más. Se están alejando de los rendimientos planos por simplemente bloquear tokens (que era el caso con su APY de staking inicialmente). En términos concretos: si haces stake en un coordinador que termina impulsando una aplicación de IA muy popular, podrías ganar una porción de las tarifas de esa aplicación, un verdadero escenario de staking como inversión en utilidad, en lugar de hacer stake solo por la inflación. Esto alinea los incentivos de todos para atraer a usuarios reales que pagan por los servicios de IA, lo que a su vez devuelve valor a los poseedores de tokens. Vale la pena señalar que la cadena de Cuckoo también tenía tarifas por transacciones (gas), por lo que los mineros que producían bloques (inicialmente los mineros de GPU también contribuían a la producción de bloques en la cadena de Cuckoo) también obtenían tarifas de gas. Con el cierre de la cadena y la migración a un rollup, las tarifas de gas probablemente serán mínimas (o en Ethereum), por lo que los ingresos principales se convierten en las propias tarifas del servicio de IA. En resumen, Cuckoo está en transición de un modelo impulsado por subsidios (la red paga a los participantes de su pool de tokens) a un modelo impulsado por la demanda (los participantes ganan de los pagos reales de los usuarios). El token seguirá desempeñando un papel en el staking y la gobernanza, pero las ganancias diarias de los mineros y los desarrolladores de aplicaciones deberían provenir cada vez más de los usuarios que compran servicios de IA. Este modelo es más sostenible a largo plazo y se asemeja mucho al reparto de ingresos de SaaS de la Web2, pero implementado a través de contratos inteligentes y tokens para mayor transparencia.

Superficies de Ataque y Vulnerabilidades​

La descentralización de la IA introduce varios desafíos de incentivos y seguridad. Ahora analizamos los vectores de ataque clave —ataques Sybil, colusión, parasitismo (freeloading) y envenenamiento de datos/modelos— y cómo cada plataforma los mitiga o permanece vulnerable a ellos:

• Ataques Sybil (identidades falsas): En una red abierta, un atacante podría crear muchas identidades (nodos) para obtener recompensas o influencia desproporcionadas.

• Bittensor: La resistencia a los ataques Sybil se proporciona principalmente por el costo de entrada. Para registrar un nuevo minero o validador en Bittensor, uno debe gastar o hacer stake de TAO; esto podría ser una quema o un requisito de fianza. Esto significa que crear N nodos falsos incurre en N veces el costo, lo que hace que los grandes enjambres Sybil sean caros. Además, el consenso de Bittensor vincula la influencia al stake y al rendimiento; un Sybil sin stake o con bajo rendimiento gana poco. Un atacante tendría que invertir mucho y también hacer que sus nodos Sybil contribuyan con trabajo útil para obtener una recompensa significativa (lo cual no es una estrategia Sybil típica). Dicho esto, si un atacante sí tiene mucho capital, podría adquirir la mayoría de los TAO y registrar muchos validadores o mineros, efectivamente un Sybil por riqueza. Esto se superpone con el escenario de ataque del 51 %: si una sola entidad controla >50 % del TAO en stake en una subred, pueden influir fuertemente en el consenso. La introducción de dTAO por parte de Bittensor ayuda un poco aquí: distribuye la influencia entre las subredes y requiere el apoyo de la comunidad en el staking para que las subredes prosperen, lo que dificulta que una entidad controle todo. Aún así, los ataques Sybil por parte de un adversario bien financiado siguen siendo una preocupación; el análisis de Arxiv señala explícitamente que el stake está bastante concentrado ahora, por lo que la barrera para un ataque mayoritario no es tan alta como se desearía. Para mitigar esto, se han sugerido propuestas como límites de stake por billetera (por ejemplo, limitar el stake efectivo en el percentil 88 para evitar que una billetera domine). En resumen, Bittensor se basa en la identidad ponderada por stake (no se pueden generar identidades baratas sin un stake proporcional) para manejar los Sybils; es razonablemente efectivo excepto bajo un atacante muy ingenioso.

• Gensyn: Los ataques Sybil en Gensyn se manifestarían como un atacante creando muchos nodos de resolutor o verificador para manipular el sistema. La defensa de Gensyn es puramente económica y criptográfica: las identidades en sí no importan, pero hacer el trabajo o depositar una garantía sí. Si un atacante crea 100 nodos de resolutor falsos pero no tienen trabajos ni stake, no logran nada. Para ganar tareas, un nodo Sybil tendría que pujar competitivamente y tener el hardware para hacer el trabajo. Si pujan por debajo sin capacidad, fallarán y perderán el stake. De manera similar, un atacante podría crear muchas identidades de verificador con la esperanza de ser elegido para verificar (si el protocolo selecciona verificadores al azar). Pero si hay demasiados, la red o el solicitante del trabajo podrían limitar el número de verificadores activos. Además, los verificadores necesitan potencialmente realizar la computación para verificarla, lo cual es costoso; tener muchos verificadores falsos no ayuda a menos que realmente puedas verificar los resultados. Un ángulo Sybil más pertinente en Gensyn es si un atacante intenta llenar la red con trabajos o respuestas falsas para hacer perder el tiempo a otros. Eso se mitiga requiriendo también un depósito de los solicitantes (un solicitante malicioso que publica trabajos falsos pierde su pago o depósito). En general, el uso de stakes/fianzas requeridas y la selección aleatoria para la verificación por parte de Gensyn significa que un atacante gana poco al tener múltiples identidades a menos que también traiga recursos proporcionales. Se convierte en un ataque más costoso en lugar de uno barato. El modelo de seguridad optimista asume al menos un verificador honesto; los Sybils tendrían que abrumar y ser todos los verificadores para hacer trampa consistentemente, lo que nuevamente nos lleva a poseer la mayoría del stake o del poder de cómputo. La resistencia Sybil de Gensyn es, por lo tanto, comparable a la de un rollup optimista: mientras haya un actor honesto, los Sybils no pueden causar un daño sistémico fácilmente.

• Cuckoo: La prevención de ataques Sybil en Cuckoo se basa en el staking y la investigación de la comunidad. Cada rol en Cuckoo (minero, coordinador, incluso usuario en algunos casos) requiere hacer stake de $CAI. Esto eleva inmediatamente el costo de las identidades Sybil: un atacante que crea 100 mineros falsos necesitaría adquirir y bloquear stake para cada uno. Además, el diseño de Cuckoo tiene un elemento humano/comunitario: los nuevos nodos necesitan ganar reputación a través de la votación en la cadena. Es poco probable que un ejército Sybil de nodos nuevos sin reputación reciba muchas tareas o la confianza de los usuarios. Los coordinadores en particular tienen que atraer usuarios; un coordinador falso sin historial no obtendría uso. Para los mineros, los coordinadores pueden ver sus estadísticas de rendimiento (tareas exitosas, etc.) en Cuckoo Scan y preferirán mineros confiables. Cuckoo también tenía un número relativamente pequeño de mineros (40 GPU en un momento en la beta), por lo que cualquier afluencia extraña de muchos nodos sería notable. El punto débil potencial es si el atacante también manipula el sistema de reputación, por ejemplo, haciendo un gran stake de CAI en sus nodos Sybil para que parezcan reputables o creando cuentas de "usuario" falsas para votarse a sí mismos. Esto es teóricamente posible, pero como todo está curado por tokens, cuesta tokens hacerlo (esencialmente estarías votando con tu propio stake en tus propios nodos). El equipo de Cuckoo también puede ajustar los parámetros de staking y recompensa si se observa un comportamiento Sybil (especialmente ahora que se está convirtiendo en un servicio de rollup más centralizado; pueden pausar o aplicar slashing a los malos actores). En resumen, los Sybils se mantienen a raya al requerir tener algo en juego (stake) y necesitar la aprobación de la comunidad. Nadie puede simplemente entrar con cientos de GPU falsas y cosechar recompensas sin una inversión significativa que los participantes honestos podrían gastar mejor en hardware real y stake.

• Colusión: Aquí consideramos a múltiples participantes que se confabulan para manipular el sistema, por ejemplo, validadores y mineros que coluden en Bittensor, o resolutores y verificadores que coluden en Gensyn, etc.

• Bittensor: La colusión ha sido identificada como una preocupación real. En el diseño original, un puñado de validadores podía coludir para siempre votar a favor de ciertos mineros o de ellos mismos, sesgando injustamente la distribución de recompensas (esto se observó como una concentración de poder en la subred raíz). El consenso Yuma proporciona cierta defensa: al tomar una mediana de las puntuaciones de los validadores y penalizar a los que se desvían, evita que un pequeño grupo en colusión impulse dramáticamente a un objetivo a menos que sean la mayoría. En otras palabras, si 3 de 10 validadores coluden para dar a un minero una puntuación súper alta pero los otros 7 no lo hacen, las puntuaciones atípicas de los coludidos se recortan y la recompensa del minero se basa en la puntuación mediana (por lo que la colusión no ayuda significativamente). Sin embargo, si los coludidos forman >50 % de los validadores (o >50 % del stake entre los validadores), efectivamente son el consenso: pueden acordar puntuaciones altas falsas y la mediana reflejará su opinión. Este es el clásico escenario de ataque del 51 %. Desafortunadamente, el estudio de Arxiv encontró algunas subredes de Bittensor donde una coalición de solo el 1-2 % de los participantes (en términos de número) controlaba la mayoría del stake, debido a la fuerte concentración de tokens. Esto significa que la colusión de unos pocos grandes poseedores era una amenaza creíble. La mitigación que Bittensor está persiguiendo a través de dTAO es democratizar la influencia: al permitir que cualquier poseedor de TAO dirija el stake a las subredes, diluye el poder de los grupos cerrados de validadores. Además, propuestas como el staking cóncavo (rendimientos decrecientes para un stake desproporcionado) y los límites de stake tienen como objetivo romper la capacidad de una entidad en colusión para acumular demasiado poder de voto. La suposición de seguridad de Bittensor ahora es similar a la prueba de participación: ninguna entidad única (o cartel) controla >50 % del stake activo. Mientras eso se mantenga, la colusión es limitada porque los validadores honestos anularán las malas puntuaciones y los propietarios de subredes en colusión no pueden aumentar arbitrariamente sus propias recompensas. Finalmente, sobre la colusión entre propietarios de subredes y validadores (por ejemplo, un propietario de subred sobornando a los validadores para que califiquen altamente a los mineros de su subred), dTAO elimina el control directo de los validadores, reemplazándolo con decisiones de los poseedores de tokens. Es más difícil coludir con "el mercado" a menos que compres todo el suministro de tokens, en cuyo caso no es realmente colusión, es una toma de control. Así que la principal técnica anti-colusión de Bittensor es el consenso algorítmico (recorte de mediana) y la amplia distribución de tokens.

• Gensyn: La colusión en Gensyn probablemente involucraría a un resolutor y un verificador (o múltiples verificadores) coludiendo para engañar al sistema. Por ejemplo, un resolutor podría producir un resultado falso y un verificador en colusión podría intencionalmente no desafiarlo (o incluso atestiguar que es correcto si el protocolo pidiera a los verificadores que lo aprobaran). Para mitigar esto, el modelo de seguridad de Gensyn requiere al menos un verificador honesto. Si todos los verificadores están en colusión con el resolutor, entonces un mal resultado no es desafiado. Gensyn aborda esto fomentando muchos verificadores independientes (cualquiera puede verificar) y por la teoría de juegos de que un verificador podría ganar una gran recompensa rompiendo la colusión y desafiando (porque obtendrían el stake del resolutor). Esencialmente, incluso si hay un grupo que acuerda coludir, cada miembro tiene un incentivo para desertar y reclamar la recompensa por sí mismo; esta es una configuración clásica del Dilema del Prisionero. La esperanza es que esto mantenga los grupos de colusión pequeños o ineficaces. Otra colusión potencial es entre múltiples resolutores para subir los precios o monopolizar las tareas. Sin embargo, dado que los desarrolladores pueden elegir dónde publicar las tareas (y las tareas no son unidades idénticas que se puedan monopolizar fácilmente), la colusión de resolutores en el precio sería difícil de coordinar globalmente; cualquier resolutor que no esté en colusión podría pujar por debajo para ganar el trabajo. La dinámica del mercado abierto contrarresta la colusión de precios, asumiendo al menos algunos participantes competitivos. Un ángulo más: colusión de verificadores para perjudicar a los resolutores, por ejemplo, verificadores acusando falsamente a resolutores honestos para robar su stake. La prueba de fraude de Gensyn es binaria y en la cadena; una acusación falsa fallaría cuando la re-computación en la cadena no encuentre ningún error, y presumiblemente el verificador malicioso perdería algo (quizás un depósito o reputación). Así que una colusión de verificadores tratando de sabotear a los resolutores sería atrapada por el proceso de verificación del protocolo. En resumen, la arquitectura de Gensyn es robusta siempre que al menos una parte en cualquier conjunto en colusión tenga un incentivo para ser honesta, una propiedad de la verificación optimista similar a requerir un minero honesto en Bitcoin para eventualmente exponer un fraude. La colusión es teóricamente posible si un atacante pudiera controlar a todos los verificadores y resolutores en una tarea (como la mayoría de la red), pero entonces podrían simplemente hacer trampa sin necesidad de colusión per se. Los incentivos criptoeconómicos están dispuestos para hacer que mantener la colusión sea irracional.

• Cuckoo: La colusión en Cuckoo podría ocurrir de varias maneras:

1. Un coordinador coludiendo con mineros: por ejemplo, un coordinador podría asignar siempre tareas a un conjunto de mineros amigos y repartir las recompensas, ignorando a otros mineros honestos. Dado que los coordinadores tienen discreción en la programación de tareas, esto puede suceder. Sin embargo, si los mineros amigos son de baja calidad, los usuarios finales podrían notar un servicio lento o deficiente y marcharse, por lo que el coordinador está desincentivado de un favoritismo puro que perjudique la calidad. Si la colusión es para manipular las recompensas (digamos, enviando tareas falsas para dar tokens a los mineros), eso se detectaría en la cadena (muchas tareas con quizás entradas idénticas o sin un usuario real) y puede ser penalizado. La transparencia en la cadena de Cuckoo significa que cualquier patrón inusual podría ser señalado por la comunidad o el equipo central. Además, debido a que todos los participantes hacen stake, un anillo de coordinador-minero en colusión se arriesga a perder su stake si son atrapados abusando del sistema (por ejemplo, si la gobernanza decide aplicarles slashing por fraude).
2. Mineros coludiendo entre ellos: podrían compartir información o formar un cartel para, digamos, votarse todos entre sí en reputación o todos negarse a servir a un coordinador en particular para extraer tarifas más altas. Estos escenarios son menos probables: la votación de reputación la realizan los stakers (incluidos los usuarios), no los propios mineros votando entre sí. Y negarse a prestar servicio solo llevaría a los coordinadores a encontrar otros mineros o a dar la alarma. Dada la escala relativamente pequeña actual, cualquier colusión sería difícil de ocultar.
3. Colusión para manipular la gobernanza: grandes poseedores de CAI podrían coludir para aprobar propuestas a su favor (como establecer una tarifa exorbitante o redirigir la tesorería). Este es un riesgo en cualquier gobernanza de tokens. La mejor mitigación es distribuir ampliamente el token (el lanzamiento justo de Cuckoo dio el 51 % a la comunidad) y tener una supervisión comunitaria activa. Además, dado que Cuckoo se alejó de la L1, la gobernanza inmediata en la cadena podría ser limitada hasta que se reasienten en una nueva cadena; el equipo probablemente retiene un control multisig en el ínterin, lo que irónicamente previene la colusión de extraños maliciosos a expensas de ser centralizado temporalmente. En general, Cuckoo se apoya en la transparencia y el staking para manejar la colusión. Hay un elemento de confianza en que los coordinadores se comporten porque quieren atraer usuarios en un entorno competitivo. Si la colusión conduce a un servicio más deficiente o a una manipulación obvia de las recompensas, las partes interesadas pueden votar en contra o dejar de hacer stake en los malos actores, y la red puede aplicarles slashing o bloquearlos. La naturaleza bastante abierta (cualquiera puede convertirse en coordinador o minero si hace stake) significa que la colusión requeriría un gran esfuerzo coordinado que sería evidente. No está tan matemáticamente prevenida como en Bittensor o Gensyn, pero la combinación de stake económico y gobernanza comunitaria proporciona un control.

• Freeloading (Problemas de parasitismo): Esto se refiere a los participantes que intentan obtener recompensas sin contribuir con un valor equivalente, por ejemplo, un validador que en realidad no evalúa pero aún así gana, o un minero que copia las respuestas de otros en lugar de computar, o usuarios que farmean recompensas sin proporcionar una entrada útil.

• Bittensor: Un problema conocido de parasitismo en Bittensor es la "copia de pesos" por parte de validadores perezosos. Un validador podría simplemente copiar la opinión de la mayoría (o las puntuaciones de otro validador) en lugar de evaluar independientemente a los mineros. Al hacerlo, evitan el costo de ejecutar consultas de IA pero aún así obtienen recompensas si sus puntuaciones enviadas parecen alineadas con el consenso. Bittensor combate esto midiendo la alineación con el consenso y la contribución informativa de cada validador. Si un validador siempre copia a otros, puede que se alinee bien (por lo que no es penalizado fuertemente), pero no agrega ningún valor único. Los desarrolladores del protocolo han discutido dar mayores recompensas a los validadores que proporcionan evaluaciones precisas pero no puramente redundantes. Técnicas como la infusión de ruido (dar deliberadamente a los validadores consultas ligeramente diferentes) podrían obligarlos a trabajar realmente en lugar de copiar, aunque no está claro si eso está implementado. El artículo de Arxiv sugiere emisiones ponderadas por rendimiento y métodos de puntuación compuesta para vincular mejor el esfuerzo del validador con la recompensa. En cuanto a los mineros, un posible comportamiento de parasitismo sería si un minero consulta a otros mineros y retransmite la respuesta (una forma de plagio). El diseño de Bittensor (con consultas descentralizadas) podría permitir que el modelo de un minero llame a otros a través de su propia dendrita. Si un minero simplemente retransmite la respuesta de otro, un buen validador podría detectarlo porque la respuesta podría no coincidir consistentemente con las capacidades del modelo declaradas por el minero. Es difícil de detectar algorítmicamente, pero un minero que nunca computa resultados originales debería eventualmente obtener una puntuación baja en algunas consultas y perder reputación. Otro escenario de parasitismo eran los delegadores que ganaban recompensas sin hacer trabajo de IA. Eso es intencional (para involucrar a los poseedores de tokens), por lo que no es un ataque, pero sí significa que algunas emisiones de tokens van a personas que solo hicieron stake. Bittensor lo justifica como una alineación de incentivos, no como recompensas desperdiciadas. En resumen, Bittensor reconoce el problema de los validadores parásitos y está ajustando los incentivos (como dar puntuaciones de confianza de validador que impulsan a aquellos que no se desvían ni copian). Su solución es esencialmente recompensar el esfuerzo y la corrección de manera más explícita, para que no hacer nada o copiar ciegamente produzca menos TAO con el tiempo.

• Gensyn: En Gensyn, a los parásitos les resultaría difícil ganar, porque uno debe proporcionar cómputo o atrapar a alguien haciendo trampa para obtener tokens. Un resolutor no puede "fingir" el trabajo; tiene que presentar una prueba válida o arriesgarse al slashing. No hay mecanismo para recibir un pago sin hacer la tarea. Un verificador podría teóricamente permanecer inactivo y esperar que otros atrapen fraudes, pero entonces no ganaría nada (porque solo el que presenta la prueba de fraude obtiene la recompensa). Si demasiados verificadores intentan parasitar (no re-computando realmente las tareas), entonces un resolutor fraudulento podría pasar desapercibido porque nadie está verificando. El diseño de incentivos de Gensyn aborda esto con la recompensa jackpot: solo se necesita un verificador activo para atrapar a un tramposo y obtener un gran pago, por lo que es racional que al menos uno siempre haga el trabajo. Otros que no trabajan no dañan la red, excepto por ser inútiles; tampoco obtienen recompensa. Así que el sistema filtra naturalmente a los parásitos: solo aquellos verificadores que realmente verifican obtendrán ganancias a largo plazo (otros gastan recursos en nodos para nada o muy raramente obtienen una recompensa por casualidad). El protocolo también podría aleatorizar qué verificador tiene la oportunidad de desafiar para desalentar que todos los verificadores asuman que "alguien más lo hará". Dado que las tareas se pagan individualmente, no hay un análogo de "recompensas de staking sin trabajo" aparte de los incentivos de la testnet que son temporales. Un área a observar es la optimización de múltiples tareas: un resolutor podría intentar reutilizar el trabajo entre tareas o subcontratarlo en secreto a alguien más barato (como usar una nube centralizada), pero eso no es realmente un parasitismo dañino; si entregan resultados correctos a tiempo, no importa cómo lo hicieron. Eso es más como arbitraje que un ataque. En resumen, el diseño del mecanismo de Gensyn deja poco espacio para que los parásitos ganen, porque cada token distribuido corresponde a un trabajo hecho o a un tramposo castigado.

• Cuckoo: La fase inicial de Cuckoo creó inadvertidamente un problema de parasitismo: el airdrop y el staking de alto rendimiento atrajeron a usuarios que solo estaban allí para farmear tokens. Estos usuarios ciclaban tokens a través de faucets o manipulaban las tareas del airdrop (por ejemplo, usando continuamente prompts de prueba gratuitos o creando muchas cuentas para reclamar recompensas) sin contribuir al valor a largo plazo de la red. Cuckoo reconoció esto como un problema: esencialmente, la gente estaba "usando" la red no por el resultado de la IA, sino para obtener una ganancia especulativa. La decisión de terminar la cadena L1 y reenfocarse fue en parte para deshacerse de estas desalineaciones de incentivos. Al vincular las futuras recompensas de tokens al uso real (es decir, ganas porque el servicio está siendo utilizado por clientes que pagan), el atractivo del parasitismo disminuye. También existe un escenario de parasitismo por parte de los mineros: un minero podría unirse, recibir tareas y de alguna manera no realizarlas pero aún así reclamar la recompensa. Sin embargo, el coordinador está verificando los resultados; si un minero no devuelve ninguna salida o una salida incorrecta, el coordinador no lo contará como una tarea completada, por lo que el minero no recibiría pago. Los mineros también podrían intentar seleccionar las tareas fáciles y abandonar las difíciles (por ejemplo, si algunos prompts son más lentos, un minero podría desconectarse para evitarlos). Esto podría ser un problema, pero los coordinadores pueden notar la fiabilidad de un minero. Si un minero se desconecta con frecuencia, el coordinador puede dejar de asignarle tareas o aplicar slashing a su stake (si existe tal mecanismo o simplemente no recompensarlo). El parasitismo de los usuarios: dado que muchos servicios de IA tienen pruebas gratuitas, un usuario podría enviar spam de solicitudes para obtener resultados sin pagar (si hay un modelo subsidiado). Eso no es tanto un problema a nivel de protocolo como a nivel de servicio; cada coordinador puede decidir cómo manejar el uso gratuito (por ejemplo, requiriendo un pequeño pago o limitando la velocidad). Debido a que Cuckoo inicialmente regaló cosas (como generaciones de imágenes de IA gratuitas para atraer usuarios), algunos se aprovecharon, pero eso era parte del marketing de crecimiento esperado. A medida que esas promociones terminen, los usuarios tendrán que pagar, por lo que no habrá almuerzo gratis que explotar. En general, la nueva estrategia de Cuckoo de mapear la distribución de tokens a la utilidad real está explícitamente dirigida a eliminar el problema del parasitismo de "minar tokens por hacer bucles sin sentido".

• Envenenamiento de Datos o Modelos: Esto se refiere a la introducción maliciosa de datos o comportamientos incorrectos de tal manera que los modelos de IA se degradan o los resultados se manipulan, así como problemas de contenido dañino o sesgado que se contribuye.

• Bittensor: El envenenamiento de datos en Bittensor significaría que un minero da intencionalmente respuestas incorrectas o dañinas, o que los validadores evalúan a propósito las buenas respuestas como malas. Si un minero produce basura o contenido malicioso de manera consistente, los validadores le darán puntuaciones bajas, y ese minero ganará poco y eventualmente se retirará; el incentivo económico es proporcionar calidad, por lo que "envenenar" a otros no produce ningún beneficio para el atacante (a menos que su objetivo sea puramente el sabotaje a su propio costo). ¿Podría un minero malicioso envenenar a otros? En Bittensor, los mineros no se entrenan directamente entre sí (al menos no por diseño; no hay un modelo global que se esté actualizando que pueda ser envenenado). El modelo de cada minero es independiente. Sí aprenden en el sentido de que un minero podría tomar muestras interesantes de otros para ajustarse, pero eso es completamente opcional y depende de cada uno. Si un actor malicioso enviara spam de respuestas sin sentido, los validadores honestos lo filtrarían (le darían una puntuación baja), por lo que no influiría significativamente en el proceso de entrenamiento de ningún minero honesto (además, un minero probablemente usaría el conocimiento de sus pares con alta puntuación, no de los de baja puntuación). Así que el envenenamiento de datos clásico (inyectar datos de entrenamiento malos para corromper un modelo) es mínimo en la configuración actual de Bittensor. El riesgo más relevante es la manipulación de la respuesta del modelo: por ejemplo, un minero que produce contenido sutilmente sesgado o peligroso que no es obvio para los validadores. Sin embargo, dado que los validadores también son diseñados por humanos o al menos agentes algorítmicos, es probable que se detecte la toxicidad o el error flagrante (algunas subredes incluso podrían tener validadores de IA que verifiquen contenido inseguro). Un escenario del peor de los casos es si un atacante de alguna manera tuviera la mayoría de los validadores y mineros coludiendo para impulsar una cierta salida incorrecta como "correcta"; entonces podrían sesgar el consenso de la red sobre las respuestas (como todos los validadores en colusión votando a favor de una respuesta maliciosa). Pero para que un usuario externo se vea perjudicado por eso, tendría que consultar realmente la red y confiar en la salida. Bittensor todavía está en una fase en la que está construyendo capacidad, no siendo ampliamente utilizado para consultas críticas por parte de los usuarios finales. Para cuando lo sea, se espera que tenga filtrado de contenido y diversidad de validadores para mitigar tales riesgos. Por el lado del validador, un validador malicioso podría alimentar evaluaciones envenenadas, por ejemplo, votando consistentemente en contra de un cierto minero honesto para eliminar la competencia. Con suficiente stake, podrían tener éxito en expulsar a ese minero (si las recompensas del minero caen tan bajo que se van). Este es un ataque al mecanismo de incentivos. Nuevamente, si no son mayoría, el recorte de la mediana frustrará a un validador atípico. Si son mayoría, se fusiona con el escenario de colusión/51 %: cualquier mayoría puede reescribir las reglas. La solución vuelve a la descentralización: evitar que una sola entidad domine. En resumen, el diseño de Bittensor inherentemente penaliza las contribuciones de datos/modelos envenenados a través de su sistema de puntuación: las malas contribuciones obtienen un peso bajo y, por lo tanto, una baja recompensa. No hay un repositorio de modelos permanente que envenenar; todo es dinámico y se evalúa continuamente. Esto proporciona resiliencia: la red puede "olvidar" o ignorar gradualmente a los malos actores a medida que sus contribuciones son filtradas por los validadores.

• Gensyn: Si un resolutor quisiera envenenar un modelo que se está entrenando (como introducir una puerta trasera o un sesgo durante el entrenamiento), podría intentar hacerlo de forma encubierta. El protocolo de Gensyn verificaría que el entrenamiento procedió de acuerdo con el algoritmo especificado (pasos de descenso de gradiente estocástico, etc.), pero no necesariamente detectaría si el resolutor introdujo un sutil activador de puerta trasera que no aparece en las métricas de validación normales. Este es un problema más insidioso: no es un fallo de la computación, es una manipulación dentro de los grados de libertad permitidos del entrenamiento (como ajustar los pesos hacia una frase activadora). Detectar eso es un problema de investigación activo en seguridad de ML. Gensyn no tiene un mecanismo especial para el envenenamiento de modelos más allá del hecho de que el solicitante podría evaluar el modelo final en un conjunto de prueba de su elección. Un solicitante inteligente siempre debería probar el modelo devuelto; si encuentra que falla en algunas entradas o tiene un comportamiento extraño, puede disputar el resultado o negarse a pagar. Quizás el protocolo podría permitir que un solicitante especifique ciertos criterios de aceptación (como "el modelo debe alcanzar al menos una precisión X en este conjunto de prueba secreto") y si el resultado del resolutor falla, el resolutor no recibe el pago completo. Esto disuadiría el envenenamiento porque el atacante no cumpliría los criterios de evaluación. Sin embargo, si el veneno no afecta la precisión en las pruebas normales, podría pasar desapercibido. Los verificadores en Gensyn solo comprueban la integridad de la computación, no la calidad del modelo, por lo que no detectarían un sobreajuste intencional o troyanos siempre que los registros de entrenamiento parezcan válidos. Por lo tanto, esto sigue siendo un problema de confianza a nivel de tarea: el solicitante tiene que confiar en que el resolutor no envenenará el modelo o usar métodos como el ensamblaje de múltiples resultados de entrenamiento de diferentes resolutores para diluir la influencia de un solo resolutor. Otro ángulo es el envenenamiento de datos: si el solicitante proporciona datos de entrenamiento, un resolutor malicioso podría ignorar esos datos y entrenar con otra cosa o agregar datos basura. Pero eso probablemente reduciría la precisión, lo que el solicitante notaría en el rendimiento del modelo de salida. El resolutor entonces no recibiría el pago completo (ya que presumiblemente quieren cumplir un objetivo de rendimiento). Así que el envenenamiento que degrada el rendimiento es contraproducente para la recompensa del resolutor. Solo un veneno que es neutral en rendimiento pero malicioso (una puerta trasera) es un peligro real, y eso está fuera del alcance de la verificación típica de blockchain; es un desafío de seguridad del aprendizaje automático. La mejor mitigación de Gensyn es probablemente social: usar modelos de reputación conocida, tener múltiples ejecuciones de entrenamiento, usar herramientas de código abierto. En tareas de inferencia (si Gensyn también se usa para trabajos de inferencia), un resolutor en colusión podría devolver salidas incorrectas que sesguen una cierta respuesta. Pero los verificadores detectarían las salidas incorrectas si ejecutan el mismo modelo, por lo que eso es menos un envenenamiento y más simplemente hacer trampa, lo que las pruebas de fraude abordan. En resumen, Gensyn asegura el proceso, no la intención. Asegura que el entrenamiento/inferencia se realizó correctamente, pero no que el resultado sea bueno o libre de maldades ocultas. Eso sigue siendo un problema abierto, y el whitepaper de Gensyn probablemente no lo resuelve por completo todavía (pocos lo hacen).

• Cuckoo: Dado que Cuckoo actualmente se enfoca en la inferencia (servir modelos existentes), el riesgo de envenenamiento de datos/modelos se limita relativamente a la manipulación de la salida o al envenenamiento de contenido. Un minero malicioso podría intentar manipular el modelo que se le da para ejecutar; por ejemplo, si se le proporciona un punto de control de Stable Diffusion, podría cambiarlo por un modelo diferente que quizás inserte alguna marca de agua sutil o publicidad en cada imagen. Sin embargo, el coordinador (que es el propietario del modelo) típicamente envía tareas con una expectativa del formato de salida; si un minero devuelve salidas fuera de especificación de manera consistente, el coordinador marcará y prohibirá a ese minero. Además, los mineros no pueden modificar fácilmente un modelo sin afectar notablemente sus salidas. Otro escenario es si Cuckoo introduce modelos entrenados por la comunidad: entonces los mineros o proveedores de datos podrían intentar envenenar los datos de entrenamiento (por ejemplo, introduciendo muchas etiquetas incorrectas o texto sesgado). Cuckoo necesitaría implementar la validación de datos de crowdsourcing o la ponderación de los contribuyentes. Esto aún no es una característica, pero el interés del equipo en la IA personalizada (como su mención de un entrenador de vida de IA o aplicaciones de aprendizaje) significa que eventualmente podrían manejar datos de entrenamiento proporcionados por el usuario, lo que requerirá verificaciones cuidadosas. En cuanto a la seguridad del contenido, dado que los mineros de Cuckoo realizan inferencias, uno podría preocuparse de que produzcan contenido dañino incluso si el modelo normalmente no lo haría. Pero los mineros no tienen un incentivo para alterar las salidas arbitrariamente; se les paga por la computación correcta, no por la creatividad. En todo caso, un minero malicioso podría saltarse la computación completa para ahorrar tiempo (por ejemplo, devolver una imagen borrosa o una respuesta genérica). El coordinador o el usuario verían eso y calificarían negativamente a ese minero (y probablemente no pagarían por esa tarea). La privacidad es otra faceta: un minero malicioso podría filtrar o registrar datos del usuario (como si un usuario ingresara texto o imágenes sensibles). Esto no es envenenamiento, pero es un ataque a la confidencialidad. La postura de privacidad de Cuckoo es que está explorando métodos de preservación de la privacidad (la mención de una VPN que preserva la privacidad en el ecosistema sugiere un enfoque futuro). Podrían incorporar técnicas como enclaves seguros o inferencia dividida para mantener los datos privados de los mineros. Aún no está implementado, pero es una consideración conocida. Finalmente, el blog de Cuckoo enfatiza la verificación efectiva de los resultados del modelo y la garantía de una operación segura del modelo descentralizado como clave para hacer viable la tokenización de modelos. Esto indica que son conscientes de que para descentralizar verdaderamente la IA, uno debe protegerse contra cosas como salidas envenenadas o modelos que funcionan mal. Posiblemente, tienen la intención de usar una combinación de incentivos criptoeconómicos (slashing de stake para malos actores) y sistemas de calificación de usuarios (los usuarios pueden marcar salidas incorrectas, y esos mineros pierden reputación). El sistema de reputación puede ayudar aquí: si un minero devuelve incluso un resultado obviamente malicioso o incorrecto, los usuarios/coordinadores pueden votarlos negativamente, afectando fuertemente su capacidad de ganancia futura. Sabiendo esto, los mineros están incentivados a ser consistentemente correctos y no introducir ningún veneno. En esencia, Cuckoo se basa en la confianza pero verifica: es más tradicional en el sentido de que si alguien se comporta mal, lo identificas y lo eliminas (con la pérdida de stake como castigo). Todavía no tiene defensas especializadas para el envenenamiento sutil de modelos, pero la estructura de tener propietarios de aplicaciones específicos (coordinadores) a cargo agrega una capa de supervisión; esos propietarios estarán motivados para asegurarse de que nada comprometa la integridad de su modelo, ya que sus propios ingresos y reputación dependen de ello.

En conclusión, si bien las redes de IA descentralizadas introducen nuevas superficies de ataque, también despliegan una mezcla de defensas criptográficas, de teoría de juegos y de gobernanza comunitaria: La resistencia Sybil se maneja en gran medida requiriendo una participación económica para la participación. La resistencia a la colusión proviene de la alineación de incentivos (el comportamiento honesto es más rentable) y mecanismos de consenso que limitan el impacto de pequeños grupos en colusión. La prevención del parasitismo (freerider) se logra vinculando estrechamente las recompensas con el trabajo útil real y penalizando o eliminando a aquellos que no contribuyen en nada. El envenenamiento y ataques relacionados siguen siendo desafiantes, pero los sistemas mitigan los casos flagrantes a través de la evaluación continua y la capacidad de aplicar slashing o expulsar a los actores maliciosos. Estas plataformas están investigando e iterando activamente en estos diseños, como lo demuestran los continuos ajustes de Bittensor a Yuma y dTAO, y el cambio de Cuckoo en la economía de sus tokens, para garantizar un ecosistema de IA descentralizado, seguro y autosostenible.

Evaluación Comparativa​

Para resaltar las diferencias y similitudes de Bittensor, Gensyn y Cuckoo AI, la siguiente tabla proporciona una comparación lado a lado a través de dimensiones clave:

Dimensión	Bittensor (TAO)	Gensyn	Cuckoo AI (CAI)
Pila Tecnológica	L1 personalizada (cadena Subtensor basada en Substrate) con más de 93 subredes de IA especializadas. Compatible con EVM (después de una actualización reciente) en su propia cadena.	Rollup basado en Ethereum (originalmente se planeó una L1, ahora es un rollup de ETH). Cómputo fuera de la cadena con verificación en la cadena.	Lanzada como una cadena de Capa 2 de Arbitrum Orbit (rollup EVM). Plataforma full-stack (cadena propia + cómputo + UI de aplicación). Migrando de una L1 personalizada a la seguridad compartida de Ethereum (rollup/AVS).
Enfoque Principal	Red de IA descentralizada de modelos ("internet neuronal"). Los nodos contribuyen a la inferencia y entrenamiento de modelos colectivos en diversas tareas (LLM, visión, etc.).	Mercado de cómputo descentralizado para ML. Énfasis en el entrenamiento de modelos e inferencia fuera de la cadena por GPUs globales, verificando el trabajo a través de la blockchain.	Plataforma de servicios de IA descentralizada. Enfoque en el servicio/inferencia de modelos (por ejemplo, arte generativo, API de LLM) utilizando mineros de GPU distribuidos. Integra aplicaciones de usuario final con un mercado de GPU backend.
Roles Clave	Propietario de Subred: define la tarea y la validación en una subred (gana el 18 % de las recompensas). Mineros: ejecutan modelos de IA (inferencia/entrenamiento), proporcionan respuestas. Validadores: plantean consultas y califican los resultados de los mineros (curan la calidad). Delegadores: hacen stake de TAO en mineros/validadores para amplificar y ganar una parte.	Solicitante (Desarrollador): publica un trabajo de ML (con modelo/datos) y el pago. Resolutor: computa la tarea en su hardware, envía el resultado. Verificador (Vigilante): comprueba el resultado del resolutor; puede desafiar mediante una prueba de fraude si es incorrecto. (No hay un rol de "propietario" distinto ya que el solicitante proporciona el modelo; los roles de gobernanza son a través de los poseedores de tokens).	Constructor de Aplicaciones de IA (Coordinador): despliega un servicio de modelo de IA, hace stake de CAI, gestiona tareas para los mineros. Minero (Proveedor de GPU/CPU): hace stake de CAI, realiza tareas de inferencia asignadas, devuelve resultados. Usuario Final: utiliza aplicaciones de IA (paga en cripto o contribuye con recursos). Staker (Delegador): hace stake en coordinadores/mineros, vota en la gobernanza, gana una parte de las recompensas.
Consenso y Verificación	Consenso Yuma: "prueba de inteligencia" personalizada: las puntuaciones de los validadores sobre los resultados de IA se agregan (mediana ponderada por stake) para determinar las recompensas de los mineros. El consenso de la cadena subyacente es similar a PoS (Substrate) para los bloques, pero la validez del bloque depende del consenso de IA en cada época. Resistente a puntuaciones atípicas y colusión hasta el 50 %.	Verificación optimista (estilo Truebit): se asume que el resultado del resolutor es correcto a menos que un verificador lo desafíe. Utiliza pruebas de fraude interactivas en la cadena para señalar cualquier paso incorrecto. También implementa pruebas criptográficas de computación (prueba de aprendizaje) para validar el progreso del entrenamiento sin re-ejecución. Ethereum proporciona el consenso base para las transacciones.	Cadena de Prueba de Participación (PoS) + validación de tareas por coordinadores: La Cuckoo Chain usaba validadores PoS para la producción de bloques (inicialmente, los mineros también ayudaban a asegurar los bloques). Los resultados de las tareas de IA son verificados por los nodos coordinadores (que comprueban los resultados de los mineros contra el comportamiento esperado del modelo). Aún no hay pruebas criptográficas especializadas; se basa en el stake y la reputación (sin confianza en la medida en que el mal comportamiento conduce a slashing o votación negativa en lugar de una detección automática por prueba matemática). Transición al consenso de Ethereum (rollup) para la seguridad del libro mayor.
Token y Utilidad	Token TAO: moneda nativa en Subtensor. Se utiliza para staking (requerido para registrarse e influir en el consenso), tarifas de transacción/pagos (por ejemplo, pagar por consultas de IA), y como recompensa por contribuciones (minería/validación). TAO tiene una inflación continua (1 TAO por bloque de 12s) que impulsa el mecanismo de recompensa. También se usa en la gobernanza (staking de dTAO en subredes).	Token Gensyn (ERC-20, nombre por anunciar): la unidad del protocolo para pagos (los desarrolladores pagan a los resolutores con él). Funciona como garantía de stake (los resolutores/verificadores depositan tokens y son penalizados con slashing por fallos). Se usará en la gobernanza (votación sobre actualizaciones del protocolo a través de la DAO de la Fundación Gensyn). Aún no hay detalles sobre el suministro; probablemente una porción se asigne para incentivar la adopción temprana (testnet, etc.).	Token CAI (ERC-20): token nativo de la Cuckoo Chain (1 mil millones de suministro fijo). Multipropósito: tarifa de gas para transacciones en la Cuckoo Chain, staking para roles de red (mineros, coordinadores deben bloquear CAI), votación de gobernanza sobre decisiones del protocolo, y recompensas por contribuciones (las recompensas de minería/staking provenían de la asignación inicial). También tiene un atractivo de meme (aspecto de token comunitario).
Tokenización de Activos	Cómputo: sí – el trabajo de cómputo de IA se tokeniza a través de recompensas de TAO (piensa en TAO como "gas" para la inteligencia). Modelos: indirectamente – los modelos ganan TAO según su rendimiento, pero los modelos/pesos en sí no son activos en la cadena (no hay NFT para modelos). La propiedad de la subred está tokenizada (NFT de propietario de subred + tokens alfa) para representar una participación en un mercado de modelos. Datos: no tokenizados (los datos están fuera de la cadena; Bittensor se enfoca en los resultados de los modelos en lugar de los conjuntos de datos).	Cómputo: sí – el cómputo inactivo se convierte en una mercancía en la cadena, comercializada en un mercado de trabajos por tokens. Modelos: no explícitamente – los modelos son proporcionados fuera de la cadena por los desarrolladores, y los resultados se devuelven; no hay tokens de modelo incorporados (aunque el protocolo podría facilitar la concesión de licencias si las partes lo configuran). Datos: no – los conjuntos de datos se manejan fuera de la cadena entre el solicitante y el resolutor (podrían estar encriptados o protegidos, pero no representados como activos en la cadena). La visión de Gensyn incluye posiblemente el comercio de algoritmos o datos como el cómputo, pero la implementación principal se centra en el cómputo.	Cómputo: sí – el tiempo de GPU se tokeniza a través de pagos diarios de CAI y recompensas por tareas. La red trata el poder de cómputo como un recurso que los mineros "venden" por CAI. Modelos: parcialmente – la plataforma integra modelos como servicios; sin embargo, los modelos en sí no se acuñan como NFT. El valor de un modelo se captura en la capacidad del coordinador para ganar CAI de los usuarios que lo utilizan. Los planes futuros insinúan modelos de propiedad comunitaria, pero actualmente la PI del modelo está fuera de la cadena (propiedad de quien ejecuta el coordinador). Datos: no hay tokenización general de datos. Las entradas/salidas de los usuarios son transitorias. (Cuckoo se asocia con aplicaciones como Beancount, etc., pero los datos no están representados por tokens en la cadena).
Gobernanza	Descentralizada, impulsada por los poseedores de tokens (dTAO): Inicialmente tenía 64 validadores electos que ejecutaban el consenso raíz; ahora la gobernanza es abierta: los poseedores de TAO hacen stake en subredes para dirigir las emisiones (asignación de recursos basada en el mercado). Las actualizaciones y cambios del protocolo se deciden a través de propuestas en la cadena (votación de TAO, con la Fundación/consejo de Bittensor facilitando). El objetivo es ser completamente gobernado por la comunidad, con la fundación cediendo gradualmente el control.	Descentralización progresiva: La Fundación Gensyn + un consejo electo gestionan las decisiones tempranas. Después del lanzamiento del token, la gobernanza pasará a una DAO donde los poseedores de tokens votan sobre propuestas (similar a muchos proyectos DeFi). El entorno de seguridad compartida de Ethereum significa que los cambios importantes involucran a la comunidad y potencialmente a la gobernanza de la Capa 1. El alcance de la gobernanza incluye parámetros económicos, actualizaciones de contratos (sujetas a auditorías de seguridad). Aún no está en vivo, pero se describe en el litepaper para después de la mainnet.	Mixta comunidad y fundación: Cuckoo se lanzó con un ethos de "lanzamiento justo" (sin pre-minado para insiders). Se pretende una DAO comunitaria, con votación de CAI sobre decisiones clave y actualizaciones del protocolo. En la práctica, el equipo central (desarrolladores de Cuckoo Network) ha liderado decisiones importantes (como el cierre de la cadena), pero comparten la justificación de forma transparente y la posicionan como una evolución para el beneficio de la comunidad. Es probable que las características de gobernanza en la cadena (propuestas, votación) lleguen cuando el nuevo rollup esté en su lugar. El staking también da influencia en la gobernanza de manera informal a través del sistema de reputación (votos ponderados por stake para nodos de confianza).
Modelo de Incentivos	Recompensas inflacionarias vinculadas a la contribución: ~1 TAO por bloque distribuido a los participantes según el rendimiento. Calidad = más recompensa. Mineros y validadores ganan continuamente (bloque a bloque), además los delegadores ganan una parte. TAO también es utilizado por los usuarios finales para pagar por servicios (creando un lado de demanda para el token). La economía del token está diseñada para fomentar la participación a largo plazo (staking) y la mejora constante de los modelos, similar a los mineros de Bitcoin pero "minando IA". Los problemas potenciales (centralización del stake que conduce a recompensas desalineadas) se están abordando mediante ajustes de incentivos.	Impulsado por el mercado, pago por resultados: Sin rendimiento inflacionario continuo (más allá de posibles incentivos iniciales); los resolutores solo reciben pago cuando hacen el trabajo con éxito. Los verificadores solo reciben pago al atrapar un fraude (incentivo jackpot). Esto crea una economía directa: el gasto de los desarrolladores = las ganancias de los proveedores. El valor del token está ligado a la demanda real de cómputo. Para arrancar, Gensyn probablemente recompense a los usuarios de la testnet en el lanzamiento (distribución única), pero en estado estable, se basa en el uso. Esto alinea estrechamente los incentivos con la utilidad de la red (si los trabajos de IA aumentan, el uso del token aumenta, beneficiando a todos los poseedores).	Híbrido (pasando de la inflación a las tarifas de uso): Inicialmente, las asignaciones de minería y staking del pool comunitario del 51 % recompensaban a los mineros de GPU (30 % del suministro) y a los stakers (11 %) independientemente del uso externo; esto era para impulsar los efectos de red. Con el tiempo, y especialmente después del cierre de la L1, el énfasis está en el reparto de ingresos: los mineros y los desarrolladores de aplicaciones ganan de los pagos reales de los usuarios (por ejemplo, dividiendo las tarifas por una generación de imágenes). El rendimiento de los stakers se derivará de una porción del uso real o se ajustará para fomentar el apoyo solo a nodos productivos. Así que el incentivo inicial era "hacer crecer la red" (alto APY, airdrops) y más tarde es "la red crece si es realmente útil" (ganancias de los clientes). Esta transición está diseñada para eliminar a los parásitos y garantizar la sostenibilidad.
Seguridad y Mitigaciones de Ataques	Sybil: El registro costoso (stake de TAO) disuade a los Sybils. Colusión: El consenso de mediana resiste la colusión hasta el 50 % del stake; dTAO rompió una oligarquía de validadores al empoderar la votación de los poseedores de tokens. Deshonestidad: Los validadores que se desvían del consenso pierden parte de la recompensa (incentiva la puntuación honesta). El ataque del 51 % es posible si el stake está muy concentrado; la investigación sugiere agregar límites de stake y slashing por rendimiento para mitigarlo. Ataques a modelos: Los resultados de modelos deficientes o maliciosos son penalizados con bajas puntuaciones. No hay un único punto de fallo: la red está descentralizada globalmente (los mineros de TAO existen en todo el mundo, pseudoanónimos).	Sybil: Requiere una participación económica; los nodos falsos sin stake/trabajo no ganan nada. Verificación: Se necesita al menos un verificador honesto; si es así, cualquier resultado incorrecto es atrapado y penalizado. Utiliza incentivos criptoeconómicos para que hacer trampa no sea rentable (el resolutor pierde el depósito, el verificador gana). Colusión: Seguro siempre que no todas las partes coludan; uno honesto rompe el esquema al revelar el fraude. Confianza: No depende de la confianza en el hardware o las empresas, solo en la teoría de juegos económicos y la criptografía. Ataques: Difícil de censurar o hacer DoS ya que las tareas están distribuidas; un atacante necesitaría superar en la puja a los nodos honestos o vencer consistentemente la prueba de fraude (poco probable sin el control mayoritario). Sin embargo, las puertas traseras sutiles en los modelos podrían evadir la detección, lo cual es un desafío conocido (mitigado por las pruebas de usuario y posiblemente futuras auditorías más allá de la ejecución correcta). La seguridad general es análoga a un rollup optimista para el cómputo.	Sybil: Todos los actores deben hacer stake de CAI, elevando la barrera para los Sybils. Además, un sistema de reputación (staking + votación) significa que las identidades Sybil sin reputación no obtendrán tareas. Mal comportamiento de los nodos: Los coordinadores pueden eliminar a los mineros de bajo rendimiento o sospechosos; los stakers pueden retirar su apoyo. El protocolo puede aplicar slashing al stake por fraude probado (la L1 tenía condiciones de slashing para el consenso; algo similar podría aplicarse al fraude en las tareas). Colusión: Parcialmente basada en la confianza; se basa en la competencia abierta y la supervisión de la comunidad para evitar que la colusión domine. Dado que las tareas y los pagos son públicos en la cadena, la colusión flagrante puede ser identificada y castigada socialmente o a través de la gobernanza. Protección del usuario: Los usuarios pueden cambiar de proveedor si uno es censurado o corrompido, asegurando que no haya un único punto de control. Envenenamiento/contenido: Por diseño, los mineros ejecutan los modelos proporcionados tal cual; si alteran las salidas maliciosamente, pierden reputación y recompensas. El sistema apuesta por actores racionales: como todos tienen valor en stake y potencial de ganancia futuro, están desincentivados de ataques que socavarían la confianza en la red (reforzado por las duras lecciones de su experimento L1 sobre alinear incentivos con utilidad).

Tabla: Comparación de características de Bittensor, Gensyn y Cuckoo AI en arquitectura, enfoque, roles, consenso, tokens, tokenización de activos, gobernanza, incentivos y seguridad.

El auge de la IA generativa ha sido nada menos que explosivo. Desde impresionantes obras de arte digital hasta textos con apariencia humana, la IA está creando contenido a una escala sin precedentes. Pero este boom tiene un lado oscuro: ¿de dónde obtiene la IA sus datos de entrenamiento? A menudo, provienen de la vasta extensión de internet: arte, música y escritos creados por humanos que no reciben crédito ni compensación.

Entra Camp Network, un nuevo proyecto de blockchain que busca resolver este problema fundamental. No es solo otra plataforma cripto; es una “Capa de Propiedad Intelectual Autónoma” diseñada para dar a los creadores la propiedad y el control sobre su trabajo en la era de la IA. Veamos qué hace de Camp Network un proyecto a seguir.

---

¿Cuál es la gran idea?​

En esencia, Camp Network es una blockchain que actúa como un registro global y verificable de propiedad intelectual (IP). La misión es permitir que cualquiera —desde un artista independiente hasta un usuario de redes sociales— registre su contenido en cadena. Esto crea un registro permanente e inalterable de propiedad y procedencia.

¿Por qué importa? Cuando un modelo de IA utiliza contenido registrado en Camp, los contratos inteligentes de la red pueden hacer cumplir automáticamente los términos de licencia. Esto significa que el creador original puede obtener atribución e incluso recibir pagos de regalías al instante. La visión de Camp es construir una nueva economía de creadores donde la compensación no sea una reflexión posterior; esté integrada directamente en el protocolo.

---

Bajo el capó: la pila tecnológica​

Camp no es solo un concepto; está respaldado por tecnología seria diseñada para alto rendimiento y facilidad de desarrollo.

• Arquitectura modular: Camp está construido como un rollup soberano usando Celestia para la disponibilidad de datos. Este diseño le permite ser increíblemente rápido (objetivo de 50 000 transacciones por segundo) y económico, mientras sigue siendo totalmente compatible con las herramientas de Ethereum (EVM).
• Prueba de Procedencia (PoP): Este es el mecanismo de consenso único de Camp. En lugar de depender de la minería intensiva en energía, la seguridad de la red está vinculada a la verificación del origen del contenido. Cada transacción refuerza la procedencia de la IP en la red, haciendo que la propiedad sea “ejecutable por diseño”.
• Estrategia de doble VM: Para maximizar el rendimiento, Camp está integrando la Solana Virtual Machine (SVM) junto con su compatibilidad EVM. Esto permite a los desarrolladores elegir el entorno más adecuado para su aplicación, especialmente en casos de uso de alto rendimiento como interacciones de IA en tiempo real.
• Kits para creadores y IA: Camp ofrece dos marcos clave:
  • Origin Framework: Un sistema fácil de usar para que los creadores registren su IP, la tokenicen (como NFT) e incorporen reglas de licencia.
  • mAItrix Framework: Un kit de herramientas para que los desarrolladores construyan y desplieguen agentes de IA que puedan interactuar con la IP on‑chain de forma segura y con permisos.

---

Personas, alianzas y avances​

Una idea solo es tan buena como su ejecución, y Camp parece estar ejecutando bien.

El equipo y la financiación​

El proyecto está liderado por un equipo con una combinación potente de experiencia en The Raine Group (medios y acuerdos de IP), Goldman Sachs, Figma y CoinList. Esta mezcla de finanzas, productos tecnológicos y experiencia en ingeniería cripto les ha permitido asegurar 30 millones de dólares en financiación de VCs de primer nivel como 1kx, Blockchain Capital y Maven 11.

Un ecosistema en crecimiento​

Camp ha sido agresivo en construir alianzas. La más significativa es una participación estratégica en KOR Protocol, una plataforma para tokenizar IP musical que trabaja con artistas de renombre como Deadmau5 y franquicias como Black Mirror. Esta única alianza brinda a Camp una biblioteca masiva de contenido de alto perfil con derechos claros. Otros colaboradores clave incluyen:

• RewardedTV: Plataforma descentralizada de streaming de video que usa Camp para derechos de contenido on‑chain.
• Rarible: Mercado de NFT integrado para el comercio de activos de IP.
• LayerZero: Protocolo cross‑chain que garantiza interoperabilidad con otras blockchains.

Hoja de ruta y comunidad​

Tras campañas exitosas de testnet incentivado que atrajeron a decenas de miles de usuarios (recompensándolos con puntos que se convertirán en tokens), Camp apunta a un lanzamiento de mainnet en el Q3 2025. Esto irá acompañado de un Evento de Generación de Tokens para su token nativo, $CAMP, que se usará para tarifas de gas, staking y gobernanza. El proyecto ya ha cultivado una comunidad apasionada dispuesta a construir y usar la plataforma desde el primer día.

---

¿Cómo se compara?​

Camp Network no está solo en este espacio. Enfrenta una competencia fuerte de proyectos como Story Protocol, respaldado por a16z, y Soneium, vinculado a Sony. Sin embargo, Camp se diferencia en varios aspectos clave:

1. Enfoque de abajo hacia arriba: Mientras los competidores parecen dirigirse a grandes titulares de IP corporativa, Camp se centra en empoderar a creadores independientes y comunidades cripto mediante incentivos tokenizados.
2. Solución integral: Ofrece un conjunto completo de herramientas, desde un registro de IP hasta un marco de agentes de IA, posicionándose como una solución “todo en uno”.
3. Rendimiento y escalabilidad: Su arquitectura modular y soporte de doble VM están diseñados para las altas demandas de rendimiento de IA y medios.

Conclusión​

Camp Network está presentando un caso convincente para convertirse en la capa fundamental de la propiedad intelectual en la era Web3. Al combinar tecnología innovadora, un equipo sólido, alianzas estratégicas y una ética centrada en la comunidad, está construyendo una solución práctica a uno de los problemas más urgentes creados por la IA generativa.

La verdadera prueba llegará con el lanzamiento de la mainnet y la adopción en el mundo real. Pero con una visión clara y una ejecución fuerte hasta ahora, Camp Network es, sin duda, un proyecto clave a observar mientras intenta construir un futuro más equitativo para los creadores digitales.```

Por Qué BlockEden.xyz Se Preocupa​

En el mundo acelerado de Web3, la velocidad lo es todo. Entregar infraestructura de RPC y staking de calidad de producción requiere que nuestro equipo y nuestra comunidad estén constantemente a la vanguardia de la innovación. Eso implica mantenerse al día con protocolos densos, artículos revolucionarios de criptografía y debates de gobernanza que evolucionan rápidamente. Cuanto más rápido nuestra comunidad pueda absorber y comprender nuevas ideas, más rápido podrá construir la próxima generación de aplicaciones descentralizadas. Aquí es donde entra BeFreed.ai.

Qué Es BeFreed.ai​

BeFreed.ai es una startup con sede en San Francisco que tiene una misión simple pero poderosa: hacer que el aprendizaje sea alegre y personal en la era de la IA. Han creado un compañero de micro‑aprendizaje inteligente diseñado para adaptarse al estilo de vida exigente de constructores y creadores.

Ingredientes Principales:​

• Múltiples formatos → un clic: BeFreed.ai puede tomar una amplia gama de contenidos — desde libros extensos y videos detallados hasta documentos técnicos complejos — y transformarlos al instante en resúmenes rápidos, tarjetas de estudio, notas en profundidad e incluso audio al estilo podcast.
• Motor adaptativo: La plataforma está diseñada para aprender contigo. Presta atención a tu ritmo e intereses de aprendizaje, mostrando la información más relevante a continuación, en lugar de obligarte a seguir un currículo rígido y único para todos.
• Chat integrado y explicaciones “¿Por qué esto?”: ¿Tienes una pregunta? Simplemente pregúntala. BeFreed.ai permite consultas al instante para aclarar temas complejos. También brinda explicaciones que conectan los nuevos conocimientos con tus objetivos generales, haciendo el proceso de aprendizaje más significativo.
• Una comunidad de aprendizaje de 43 k miembros: El aprendizaje suele ser una actividad colectiva. BeFreed.ai fomenta una comunidad vibrante de más de 43 000 aprendices que comparten su progreso, reaccionan a contenidos perspicaces y resaltan los puntos clave, manteniendo alta la motivación y el impulso.

Por Qué Es Relevante para los Constructores de BlockEden.xyz​

Para los constructores dedicados al ecosistema BlockEden.xyz, BeFreed.ai es más que una herramienta de aprendizaje; es una ventaja estratégica. Así puede afinar tu competitividad:

• Aprovechamiento del tiempo: Convierte un whitepaper de 300 páginas en un breve audio de 10 minutos para escuchar antes de una votación de gobernanza crucial.
• Retención de contexto: Usa tarjetas de estudio y mapas mentales para consolidar tu comprensión de los detalles del protocolo que necesitarás al escribir índices de smart contracts.
• Crecimiento multidisciplinario: Amplía tu conjunto de habilidades sin salir de tu entorno de desarrollo. Aprende los fundamentos del design thinking, comprende los bucles de crecimiento o recibe consejos sobre concurrencia en Go durante tus momentos libres.
• Vocabulario compartido: Crea listas de reproducción a nivel de equipo para asegurar que cada colaborador aprenda a partir de la misma fuente de información destilada y consistente, fomentando una mejor colaboración y alineación.

Usando BeFreed con los Flujos de Trabajo de BlockEden.xyz​

Integrar BeFreed.ai en tu proceso de desarrollo existente es fluido y aporta beneficios inmediatos:

1. Suelta una especificación: Pega la URL del último PDF de tokenomics o de una llamada de desarrolladores en YouTube en BeFreed para obtener un resumen instantáneo y digerible.
2. Exporta tarjetas de estudio: Revisa conceptos clave durante las ejecuciones de CI. Esta forma de repetición es mucho más eficaz que la fatiga mental que genera el constante cambio de contexto.
3. Enlaza en la documentación: Inserta una URL de resumen de BeFreed junto a cada referencia de API en tu documentación para ayudar a los nuevos miembros del equipo a ponerse al día más rápido.
4. Mantente actualizado: Configura digestiones semanales en BeFreed sobre L2 emergentes y pon ese conocimiento en práctica de inmediato prototipando con los servicios RPC multichain de BlockEden.xyz.

Comienza​

BeFreed.ai está disponible ahora en iOS, Android y la web. Te invitamos a probarla durante tu próximo sprint de proyecto en BlockEden.xyz y experimentar cómo puede mejorar tu velocidad de aprendizaje y construcción. Nuestro equipo ya está explorando integraciones más estrechas — imagina un futuro donde un webhook convierta automáticamente cada descripción de PR fusionada en un conjunto de estudio integral.

Introducción​

La IA y la Web3 están convergiendo de maneras poderosas, con las interfaces generales de IA ahora concebidas como un tejido conectivo para la web descentralizada. Un concepto clave que emerge de esta convergencia es MCP, que se refiere a “Model Context Protocol” (Protocolo de Contexto de Modelo, introducido por Anthropic) o se describe vagamente como un Protocolo de Conexión del Metaverso en discusiones más amplias. En esencia, MCP es un marco estandarizado que permite a los sistemas de IA interactuar con herramientas y redes externas de una manera natural y segura, potencialmente “conectando” agentes de IA a cada rincón del ecosistema Web3. Este informe proporciona un análisis exhaustivo de cómo las interfaces generales de IA (como los agentes de modelos de lenguaje grandes y los sistemas neuro-simbólicos) podrían conectar todo en el mundo Web3 a través de MCP, cubriendo los antecedentes históricos, la arquitectura técnica, el panorama de la industria, los riesgos y el potencial futuro.

1. Antecedentes del Desarrollo​

1.1 La Evolución de la Web3 y sus Promesas Incumplidas​

El término “Web3” fue acuñado alrededor de 2014 para describir una web descentralizada impulsada por blockchain. La visión era ambiciosa: una internet sin permisos centrada en la propiedad del usuario. Los entusiastas imaginaron reemplazar la infraestructura centralizada de la Web2 con alternativas basadas en blockchain, como Ethereum Name Service (para DNS), Filecoin o IPFS (para almacenamiento) y DeFi para los rieles financieros. En teoría, esto arrebataría el control a las grandes plataformas tecnológicas y otorgaría a los individuos autosoberanía sobre sus datos, identidad y activos.

La realidad se quedó corta. A pesar de años de desarrollo y expectación, el impacto general de la Web3 siguió siendo marginal. Los usuarios promedio de internet no acudieron en masa a las redes sociales descentralizadas ni comenzaron a gestionar claves privadas. Las razones clave incluyeron una mala experiencia de usuario, transacciones lentas y costosas, estafas de alto perfil e incertidumbre regulatoria. La “web de propiedad” descentralizada en gran medida “no logró materializarse” más allá de una comunidad de nicho. A mediados de la década de 2020, incluso los defensores de las criptomonedas admitieron que la Web3 no había supuesto un cambio de paradigma para el usuario promedio.

Mientras tanto, la IA estaba experimentando una revolución. A medida que el capital y el talento de los desarrolladores se desplazaban de las criptomonedas a la IA, los avances transformadores en el aprendizaje profundo y los modelos fundacionales (GPT-3, GPT-4, etc.) capturaron la imaginación del público. La IA generativa demostró una utilidad clara —produciendo contenido, código y decisiones— de una manera que las aplicaciones cripto habían tenido dificultades para lograr. De hecho, el impacto de los modelos de lenguaje grandes en solo un par de años superó con creces una década de adopción de usuarios de blockchain. Este contraste llevó a algunos a bromear diciendo que “la Web3 se desperdició en las criptomonedas” y que la verdadera Web 3.0 está emergiendo de la ola de la IA.

1.2 El Auge de las Interfaces Generales de IA​

A lo largo de décadas, las interfaces de usuario evolucionaron desde páginas web estáticas (Web1.0) hasta aplicaciones interactivas (Web2.0), pero siempre dentro de los confines de hacer clic en botones y rellenar formularios. Con la IA moderna, especialmente los modelos de lenguaje grandes (LLM), ha llegado un nuevo paradigma de interfaz: el lenguaje natural. Los usuarios pueden simplemente expresar su intención en lenguaje sencillo y hacer que los sistemas de IA ejecuten acciones complejas en muchos dominios. Este cambio es tan profundo que algunos sugieren redefinir “Web 3.0” como la era de los agentes impulsados por IA (“la Web Agéntica”) en lugar de la definición anterior centrada en blockchain.

Sin embargo, los primeros experimentos con agentes de IA autónomos expusieron un cuello de botella crítico. Estos agentes —por ejemplo, prototipos como AutoGPT— podían generar texto o código, pero carecían de una forma robusta de comunicarse con sistemas externos y entre sí. No había “un lenguaje común nativo de IA” para la interoperabilidad. Cada integración con una herramienta o fuente de datos era un apaño a medida, y la interacción de IA a IA no tenía un protocolo estándar. En términos prácticos, un agente de IA podría tener una gran capacidad de razonamiento pero fallar en la ejecución de tareas que requerían el uso de aplicaciones web o servicios on-chain, simplemente porque no sabía cómo hablar con esos sistemas. Este desajuste —cerebros potentes, E/S primitiva— era similar a tener un software súper inteligente atrapado detrás de una torpe GUI.

1.3 Convergencia y el Surgimiento de MCP​

Para 2024, se hizo evidente que para que la IA alcanzara su máximo potencial (y para que la Web3 cumpliera su promesa), se necesitaba una convergencia: los agentes de IA requieren un acceso fluido a las capacidades de la Web3 (aplicaciones descentralizadas, contratos, datos), y la Web3 necesita más inteligencia y usabilidad, que la IA puede proporcionar. Este es el contexto en el que nació MCP (Model Context Protocol). Introducido por Anthropic a finales de 2024, MCP es un estándar abierto para la comunicación entre IA y herramientas que resulta natural para los LLM. Proporciona una forma estructurada y reconocible para que los “hosts” de IA (como ChatGPT, Claude, etc.) encuentren y utilicen una variedad de herramientas y recursos externos a través de servidores MCP. En otras palabras, MCP es una capa de interfaz común que permite a los agentes de IA conectarse a servicios web, APIs e incluso funciones de blockchain, sin codificar a medida cada integración.

Piense en MCP como “el USB-C de las interfaces de IA”. Así como el USB-C estandarizó cómo se conectan los dispositivos (para que no necesite cables diferentes para cada dispositivo), MCP estandariza cómo los agentes de IA se conectan a herramientas y datos. En lugar de codificar diferentes llamadas a API para cada servicio (Slack vs. Gmail vs. nodo de Ethereum), un desarrollador puede implementar la especificación MCP una vez, y cualquier IA compatible con MCP puede entender cómo usar ese servicio. Los principales actores de la IA vieron rápidamente la importancia: Anthropic hizo de código abierto a MCP, y empresas como OpenAI y Google están desarrollando soporte para él en sus modelos. Este impulso sugiere que MCP (o “Protocolos de Meta Conectividad” similares) podría convertirse en la columna vertebral que finalmente conecte la IA y la Web3 de una manera escalable.

Cabe destacar que algunos tecnólogos argumentan que esta conectividad centrada en la IA es la verdadera realización de la Web3.0. En palabras de Simba Khadder, “MCP tiene como objetivo estandarizar una API entre los LLM y las aplicaciones”, de manera similar a cómo las APIs REST permitieron la Web 2.0, lo que significa que la próxima era de la Web3 podría definirse por interfaces de agentes inteligentes en lugar de solo por blockchains. En lugar de la descentralización por sí misma, la convergencia con la IA podría hacer que la descentralización sea útil, al ocultar la complejidad detrás del lenguaje natural y los agentes autónomos. El resto de este informe profundiza en cómo, técnica y prácticamente, las interfaces generales de IA (a través de protocolos como MCP) pueden conectar todo en el mundo Web3.

2. Arquitectura Técnica: Interfaces de IA Uniendo Tecnologías Web3​

Incrustar agentes de IA en la pila de Web3 requiere integración en múltiples niveles: redes de blockchain y contratos inteligentes, almacenamiento descentralizado, sistemas de identidad y economías basadas en tokens. Las interfaces generales de IA —desde grandes modelos fundacionales hasta sistemas híbridos neuro-simbólicos— pueden servir como un “adaptador universal” que conecta estos componentes. A continuación, analizamos la arquitectura de dicha integración:

Figura: Un diagrama conceptual de la arquitectura de MCP, que muestra cómo los hosts de IA (aplicaciones basadas en LLM como Claude o ChatGPT) utilizan un cliente MCP para conectarse a varios servidores MCP. Cada servidor proporciona un puente a alguna herramienta o servicio externo (por ejemplo, Slack, Gmail, calendarios o datos locales), análogo a los periféricos que se conectan a través de un concentrador universal. Esta interfaz MCP estandarizada permite a los agentes de IA acceder a servicios remotos y recursos on-chain a través de un protocolo común.

2.1 Agentes de IA como Clientes Web3 (Integración con Blockchains)​

En el núcleo de la Web3 se encuentran las blockchains y los contratos inteligentes, máquinas de estado descentralizadas que pueden hacer cumplir la lógica sin necesidad de confianza. ¿Cómo puede una interfaz de IA interactuar con estos? Hay dos direcciones a considerar:

• IA leyendo de la blockchain: Un agente de IA puede necesitar datos on-chain (por ejemplo, precios de tokens, saldo de activos de un usuario, propuestas de DAO) como contexto para sus decisiones. Tradicionalmente, recuperar datos de la blockchain requiere interactuar con APIs RPC de nodos o bases de datos de subgrafos. Con un marco como MCP, una IA puede consultar un servidor MCP estandarizado de “datos de blockchain” para obtener información on-chain en tiempo real. Por ejemplo, un agente habilitado para MCP podría solicitar el último volumen de transacciones de un determinado token, o el estado de un contrato inteligente, y el servidor MCP se encargaría de los detalles de bajo nivel para conectarse a la blockchain y devolver los datos en un formato que la IA pueda usar. Esto aumenta la interoperabilidad al desacoplar la IA del formato de API de cualquier blockchain específica.

• IA escribiendo en la blockchain: De manera más potente, los agentes de IA pueden ejecutar llamadas a contratos inteligentes o transacciones a través de integraciones Web3. Una IA podría, por ejemplo, ejecutar autónomamente una operación en un exchange descentralizado o ajustar parámetros en un contrato inteligente si se cumplen ciertas condiciones. Esto se logra mediante la invocación por parte de la IA de un servidor MCP que encapsula la funcionalidad de transacción de la blockchain. Un ejemplo concreto es el servidor MCP de thirdweb para cadenas EVM, que permite a cualquier cliente de IA compatible con MCP interactuar con Ethereum, Polygon, BSC, etc., abstrayendo la mecánica específica de la cadena. Usando una herramienta así, un agente de IA podría desencadenar acciones on-chain “sin intervención humana”, permitiendo dApps autónomas; por ejemplo, una bóveda DeFi impulsada por IA que se reequilibra a sí misma firmando transacciones cuando cambian las condiciones del mercado.

Bajo el capó, estas interacciones todavía dependen de wallets, claves y tarifas de gas, pero a la interfaz de IA se le puede dar acceso controlado a un wallet (con sandboxes de seguridad adecuados) para realizar las transacciones. Los oráculos y los puentes entre cadenas también entran en juego: redes de oráculos como Chainlink sirven como un puente entre la IA y las blockchains, permitiendo que los resultados de la IA sean introducidos on-chain de manera confiable. El Protocolo de Interoperabilidad entre Cadenas (CCIP) de Chainlink, por ejemplo, podría permitir que un modelo de IA considerado confiable desencadene múltiples contratos en diferentes cadenas simultáneamente en nombre de un usuario. En resumen, las interfaces generales de IA pueden actuar como un nuevo tipo de cliente Web3, uno que puede tanto consumir datos de la blockchain como producir transacciones de la blockchain a través de protocolos estandarizados.

2.2 Sinergia Neuro-Simbólica: Combinando el Razonamiento de la IA con los Contratos Inteligentes​

Un aspecto intrigante de la integración IA-Web3 es el potencial de las arquitecturas neuro-simbólicas que combinan la capacidad de aprendizaje de la IA (redes neuronales) con la lógica rigurosa de los contratos inteligentes (reglas simbólicas). En la práctica, esto podría significar que los agentes de IA manejen la toma de decisiones no estructurada y pasen ciertas tareas a los contratos inteligentes para una ejecución verificable. Por ejemplo, una IA podría analizar el sentimiento del mercado (una tarea difusa), pero luego ejecutar operaciones a través de un contrato inteligente determinista que sigue reglas de riesgo preestablecidas. El marco MCP y los estándares relacionados hacen factibles tales transferencias al darle a la IA una interfaz común para llamar a funciones de contrato o para consultar las reglas de una DAO antes de actuar.

Un ejemplo concreto es el AI-DSL (Lenguaje Específico de Dominio de IA) de SingularityNET, que tiene como objetivo estandarizar la comunicación entre agentes de IA en su red descentralizada. Esto puede verse como un paso hacia la integración neuro-simbólica: un lenguaje formal (simbólico) para que los agentes soliciten servicios de IA o datos entre sí. De manera similar, proyectos como AlphaCode de DeepMind u otros podrían eventualmente conectarse para que los contratos inteligentes llamen a modelos de IA para la resolución de problemas on-chain. Aunque ejecutar grandes modelos de IA directamente on-chain es impráctico hoy en día, están surgiendo enfoques híbridos: por ejemplo, ciertas blockchains permiten la verificación de cálculos de ML a través de pruebas de conocimiento cero o ejecución confiable, lo que permite la verificación on-chain de resultados de IA off-chain. En resumen, la arquitectura técnica concibe los sistemas de IA y los contratos inteligentes de blockchain como componentes complementarios, orquestados a través de protocolos comunes: la IA se encarga de la percepción y las tareas abiertas, mientras que las blockchains proporcionan integridad, memoria y el cumplimiento de las reglas acordadas.

2.3 Almacenamiento Descentralizado y Datos para la IA​

La IA prospera con los datos, y la Web3 ofrece nuevos paradigmas para el almacenamiento y el intercambio de datos. Las redes de almacenamiento descentralizado (como IPFS/Filecoin, Arweave, Storj, etc.) pueden servir tanto como repositorios para artefactos de modelos de IA como fuentes de datos de entrenamiento, con control de acceso basado en blockchain. Una interfaz general de IA, a través de MCP o similar, podría obtener archivos o conocimiento del almacenamiento descentralizado con la misma facilidad que desde una API de Web2. Por ejemplo, un agente de IA podría extraer un conjunto de datos del mercado de Ocean Protocol o un archivo cifrado de un almacenamiento distribuido, si tiene las claves o los pagos adecuados.

Ocean Protocol en particular se ha posicionado como una plataforma de “economía de datos de IA”, utilizando blockchain para tokenizar datos e incluso servicios de IA. En Ocean, los conjuntos de datos están representados por datatokens que controlan el acceso; un agente de IA podría obtener un datatoken (quizás pagando con criptomonedas o a través de algún derecho de acceso) y luego usar un servidor MCP de Ocean para recuperar los datos reales para su análisis. El objetivo de Ocean es desbloquear “datos inactivos” para la IA, incentivando el intercambio mientras se preserva la privacidad. Por lo tanto, una IA conectada a la Web3 podría acceder a un vasto corpus descentralizado de información —desde bóvedas de datos personales hasta datos gubernamentales abiertos— que antes estaba aislado. La blockchain asegura que el uso de los datos sea transparente y pueda ser recompensado de manera justa, alimentando un ciclo virtuoso donde más datos están disponibles para la IA y más contribuciones de IA (como modelos entrenados) pueden ser monetizadas.

Los sistemas de identidad descentralizada también juegan un papel aquí (discutido más en la siguiente subsección): pueden ayudar a controlar quién o qué tiene permitido acceder a ciertos datos. Por ejemplo, a un agente de IA médico se le podría exigir que presente una credencial verificable (prueba on-chain de cumplimiento con HIPAA o similar) antes de que se le permita descifrar un conjunto de datos médicos del almacenamiento IPFS personal de un paciente. De esta manera, la arquitectura técnica asegura que los datos fluyan hacia la IA cuando sea apropiado, pero con gobernanza y registros de auditoría on-chain para hacer cumplir los permisos.

2.4 Identidad y Gestión de Agentes en un Entorno Descentralizado​

Cuando los agentes de IA autónomos operan en un ecosistema abierto como la Web3, la identidad y la confianza se vuelven primordiales. Los marcos de identidad descentralizada (DID) proporcionan una forma de establecer identidades digitales para agentes de IA que pueden ser verificadas criptográficamente. Cada agente (o el humano/organización que lo despliega) puede tener un DID y credenciales verificables asociadas que especifican sus atributos y permisos. Por ejemplo, un bot de trading de IA podría llevar una credencial emitida por un sandbox regulatorio que certifique que puede operar dentro de ciertos límites de riesgo, o un moderador de contenido de IA podría demostrar que fue creado por una organización de confianza y ha sido sometido a pruebas de sesgo.

A través de registros de identidad y sistemas de reputación on-chain, el mundo Web3 puede hacer cumplir la responsabilidad por las acciones de la IA. Cada transacción que realiza un agente de IA puede ser rastreada hasta su ID, y si algo sale mal, las credenciales te dicen quién lo construyó o quién es responsable. Esto aborda un desafío crítico: sin identidad, un actor malicioso podría crear agentes de IA falsos para explotar sistemas o difundir desinformación, y nadie podría distinguir los bots de los servicios legítimos. La identidad descentralizada ayuda a mitigar eso al permitir una autenticación robusta y distinguir los agentes de IA auténticos de las falsificaciones.

En la práctica, una interfaz de IA integrada con la Web3 usaría protocolos de identidad para firmar sus acciones y solicitudes. Por ejemplo, cuando un agente de IA llama a un servidor MCP para usar una herramienta, podría incluir un token o firma vinculada a su identidad descentralizada, para que el servidor pueda verificar que la llamada proviene de un agente autorizado. Los sistemas de identidad basados en blockchain (como el ERC-725 de Ethereum o los DID de W3C anclados en un ledger) aseguran que esta verificación sea sin confianza y verificable globalmente. El concepto emergente de “wallets de IA” se relaciona con esto: esencialmente, dar a los agentes de IA wallets de criptomonedas que están vinculados con su identidad, para que puedan gestionar claves, pagar por servicios o hacer staking de tokens como una fianza (que podría ser recortada por mal comportamiento). ArcBlock, por ejemplo, ha discutido cómo “los agentes de IA necesitan un wallet” y un DID para operar de manera responsable en entornos descentralizados.

En resumen, la arquitectura técnica prevé a los agentes de IA como ciudadanos de primera clase en la Web3, cada uno con una identidad on-chain y posiblemente una participación en el sistema, utilizando protocolos como MCP para interactuar. Esto crea una red de confianza: los contratos inteligentes pueden requerir las credenciales de una IA antes de cooperar, y los usuarios pueden optar por delegar tareas solo a aquellas IA que cumplan con ciertas certificaciones on-chain. Es una mezcla de la capacidad de la IA con las garantías de confianza de la blockchain.

2.5 Economías de Tokens e Incentivos para la IA​

La tokenización es un sello distintivo de la Web3, y se extiende también al dominio de la integración de la IA. Al introducir incentivos económicos a través de tokens, las redes pueden fomentar comportamientos deseados tanto de los desarrolladores de IA como de los propios agentes. Están surgiendo varios patrones:

• Pago por Servicios: Los modelos y servicios de IA pueden ser monetizados on-chain. SingularityNET fue pionero en esto al permitir a los desarrolladores desplegar servicios de IA y cobrar a los usuarios en un token nativo (AGIX) por cada llamada. En un futuro habilitado para MCP, uno podría imaginar cualquier herramienta o modelo de IA como un servicio plug-and-play donde el uso se mide a través de tokens o micropagos. Por ejemplo, si un agente de IA utiliza una API de visión de terceros a través de MCP, podría manejar automáticamente el pago transfiriendo tokens al contrato inteligente del proveedor de servicios. Fetch.ai de manera similar visualiza mercados donde “agentes económicos autónomos” intercambian servicios y datos, con su nuevo LLM de Web3 (ASI-1) presumiblemente integrando transacciones cripto para el intercambio de valor.

• Staking y Reputación: Para asegurar la calidad y la fiabilidad, algunos proyectos requieren que los desarrolladores o agentes hagan staking de tokens. Por ejemplo, el proyecto DeMCP (un mercado descentralizado de servidores MCP) planea usar incentivos de tokens para recompensar a los desarrolladores por crear servidores MCP útiles, y posiblemente hacer que hagan staking de tokens como señal de compromiso con la seguridad de su servidor. La reputación también podría estar vinculada a los tokens; por ejemplo, un agente que se desempeña consistentemente bien podría acumular tokens de reputación o reseñas positivas on-chain, mientras que uno que se comporta mal podría perder su stake o ganar marcas negativas. Esta reputación tokenizada puede luego retroalimentar el sistema de identidad mencionado anteriormente (los contratos inteligentes o los usuarios verifican la reputación on-chain del agente antes de confiar en él).

• Tokens de Gobernanza: Cuando los servicios de IA se convierten en parte de plataformas descentralizadas, los tokens de gobernanza permiten a la comunidad dirigir su evolución. Proyectos como SingularityNET y Ocean tienen DAOs donde los poseedores de tokens votan sobre cambios en el protocolo o la financiación de iniciativas de IA. En la Alianza de Superinteligencia Artificial (ASI) combinada —una fusión recientemente anunciada de SingularityNET, Fetch.ai y Ocean Protocol— un token unificado (ASI) está destinado a gobernar la dirección de un ecosistema conjunto de IA+blockchain. Dichos tokens de gobernanza podrían decidir políticas como qué estándares adoptar (por ejemplo, soportar MCP o protocolos A2A), qué proyectos de IA incubar o cómo manejar las directrices éticas para los agentes de IA.

• Acceso y Utilidad: Los tokens pueden controlar el acceso no solo a los datos (como con los datatokens de Ocean) sino también al uso de modelos de IA. Un escenario posible son los “NFTs de modelos” o similares, donde poseer un token te otorga derechos sobre los resultados de un modelo de IA o una participación en sus ganancias. Esto podría sustentar los mercados de IA descentralizados: imagina un NFT que representa la propiedad parcial de un modelo de alto rendimiento; los propietarios ganan colectivamente cada vez que el modelo se utiliza en tareas de inferencia, y pueden votar sobre su ajuste fino. Aunque experimental, esto se alinea con el ethos de la Web3 de propiedad compartida aplicada a los activos de IA.

En términos técnicos, integrar tokens significa que los agentes de IA necesitan funcionalidad de wallet (como se señaló, muchos tendrán sus propios wallets de criptomonedas). A través de MCP, una IA podría tener una “herramienta de wallet” que le permita verificar saldos, enviar tokens o llamar a protocolos DeFi (quizás para intercambiar un token por otro para pagar un servicio). Por ejemplo, si un agente de IA que se ejecuta en Ethereum necesita algunos tokens de Ocean para comprar un conjunto de datos, podría intercambiar automáticamente algunos ETH por $OCEAN a través de un DEX usando un plugin de MCP, y luego proceder con la compra, todo sin intervención humana, guiado por las políticas establecidas por su propietario.

En general, la economía de tokens proporciona la capa de incentivos en la arquitectura IA-Web3, asegurando que los contribuyentes (ya sea que proporcionen datos, código de modelo, poder de cómputo o auditorías de seguridad) sean recompensados, y que los agentes de IA tengan “algo en juego” que los alinee (hasta cierto punto) con las

Introducción: La Necesidad de una IA Verificable en la Blockchain​

A medida que los sistemas de IA aumentan su influencia, asegurar que sus resultados sean confiables se vuelve crítico. Los métodos tradicionales se basan en garantías institucionales (esencialmente, “solo confía en nosotros”), que no ofrecen garantías criptográficas. Esto es especialmente problemático en contextos descentralizados como las blockchains, donde un contrato inteligente o un usuario debe confiar en un resultado derivado de la IA sin poder volver a ejecutar un modelo pesado on-chain. El Aprendizaje Automático de Conocimiento Cero (zkML) aborda esto al permitir la verificación criptográfica de los cálculos de ML. En esencia, zkML permite a un probador generar una prueba sucinta de que “el resultado $Y$ provino de ejecutar el modelo $M$ en la entrada $X$” – sin revelar $X$ ni los detalles internos de $M$. Estas pruebas de conocimiento cero (ZKPs) pueden ser verificadas por cualquiera (o cualquier contrato) de manera eficiente, cambiando la confianza en la IA de la “política a la prueba”.

La verificabilidad on-chain de la IA significa que una blockchain puede incorporar cálculos avanzados (como inferencias de redes neuronales) verificando una prueba de ejecución correcta en lugar de realizar el cómputo en sí. Esto tiene amplias implicaciones: los contratos inteligentes pueden tomar decisiones basadas en predicciones de IA, los agentes autónomos descentralizados pueden demostrar que siguieron sus algoritmos, y los servicios de cómputo cross-chain u off-chain pueden proporcionar resultados verificables en lugar de oráculos no verificables. En última instancia, zkML ofrece un camino hacia una IA sin confianza y que preserva la privacidad – por ejemplo, demostrando que las decisiones de un modelo de IA son correctas y autorizadas sin exponer datos privados o los pesos del modelo propietario. Esto es clave para aplicaciones que van desde análisis de salud seguros hasta juegos en blockchain y oráculos de DeFi.

Cómo Funciona zkML: Comprimiendo la Inferencia de ML en Pruebas Sucintas​

A un alto nivel, zkML combina sistemas de pruebas criptográficas con la inferencia de ML para que una evaluación de modelo compleja pueda ser “comprimida” en una pequeña prueba. Internamente, el modelo de ML (por ejemplo, una red neuronal) se representa como un circuito o programa que consta de muchas operaciones aritméticas (multiplicaciones de matrices, funciones de activación, etc.). En lugar de revelar todos los valores intermedios, un probador realiza el cálculo completo off-chain y luego utiliza un protocolo de prueba de conocimiento cero para certificar que cada paso se realizó correctamente. El verificador, con solo la prueba y algunos datos públicos (como el resultado final y un identificador para el modelo), puede estar criptográficamente convencido de la corrección sin volver a ejecutar el modelo.

Para lograr esto, los frameworks de zkML típicamente transforman el cálculo del modelo en un formato adecuado para las ZKPs:

• Compilación de Circuitos: En los enfoques basados en SNARK, el grafo de computación del modelo se compila en un circuito aritmético o un conjunto de restricciones polinómicas. Cada capa de la red neuronal (convoluciones, multiplicaciones de matrices, activaciones no lineales) se convierte en un subcircuito con restricciones que aseguran que las salidas sean correctas dadas las entradas. Debido a que las redes neuronales involucran operaciones no lineales (ReLUs, Sigmoides, etc.) que no se adaptan naturalmente a los polinomios, se utilizan técnicas como las tablas de búsqueda para manejarlas eficientemente. Por ejemplo, una ReLU (salida = max(0, entrada)) puede ser forzada por una restricción personalizada o una búsqueda que verifica que la salida es igual a la entrada si la entrada ≥ 0, y cero en caso contrario. El resultado final es un conjunto de restricciones criptográficas que el probador debe satisfacer, lo que implícitamente demuestra que el modelo se ejecutó correctamente.
• Traza de Ejecución y Máquinas Virtuales: Una alternativa es tratar la inferencia del modelo como una traza de programa, como se hace en los enfoques de zkVM. Por ejemplo, la zkVM JOLT se enfoca en el conjunto de instrucciones RISC-V; se puede compilar el modelo de ML (o el código que lo calcula) a RISC-V y luego probar que cada instrucción de la CPU se ejecutó correctamente. JOLT introduce una técnica de “singularidad de búsqueda”, reemplazando las costosas restricciones aritméticas con búsquedas rápidas en tablas para cada operación válida de la CPU. Cada operación (suma, multiplicación, operación a nivel de bits, etc.) se verifica mediante una búsqueda en una tabla gigante de resultados válidos precalculados, utilizando un argumento especializado (Lasso/SHOUT) para mantener la eficiencia. Esto reduce drásticamente la carga de trabajo del probador: incluso las operaciones complejas de 64 bits se convierten en una sola búsqueda en la tabla en la prueba en lugar de muchas restricciones aritméticas.
• Protocolos Interactivos (GKR Sum-Check): Un tercer enfoque utiliza pruebas interactivas como GKR (Goldwasser–Kalai–Rotblum) para verificar un cálculo en capas. Aquí, el cálculo del modelo se ve como un circuito aritmético en capas (cada capa de la red neuronal es una capa del grafo del circuito). El probador ejecuta el modelo normalmente pero luego participa en un protocolo sum-check para demostrar que las salidas de cada capa son correctas dadas sus entradas. En el enfoque de Lagrange (DeepProve, detallado a continuación), el probador y el verificador realizan un protocolo polinómico interactivo (hecho no interactivo a través de Fiat-Shamir) que verifica la consistencia de los cálculos de cada capa sin rehacerlos. Este método de sum-check evita generar un circuito estático monolítico; en su lugar, verifica la consistencia de los cálculos paso a paso con operaciones criptográficas mínimas (principalmente hashing o evaluaciones de polinomios).

Independientemente del enfoque, el resultado es una prueba sucinta (típicamente de unos pocos kilobytes a unas pocas decenas de kilobytes) que certifica la corrección de toda la inferencia. La prueba es de conocimiento cero, lo que significa que cualquier entrada secreta (datos privados o parámetros del modelo) puede mantenerse oculta – influyen en la prueba pero no se revelan a los verificadores. Solo se revelan las salidas o afirmaciones públicas deseadas. Esto permite escenarios como “probar que el modelo $M$ aplicado a los datos del paciente $X$ produce el diagnóstico $Y$, sin revelar $X$ ni los pesos del modelo”.

Habilitando la verificación on-chain: Una vez que se genera una prueba, se puede publicar en una blockchain. Los contratos inteligentes pueden incluir lógica de verificación para comprobar la prueba, a menudo utilizando primitivas criptográficas precompiladas. Por ejemplo, Ethereum tiene precompilaciones para las operaciones de emparejamiento BLS12-381 utilizadas en muchos verificadores de zk-SNARK, lo que hace que la verificación on-chain de las pruebas SNARK sea eficiente. Las STARKs (pruebas basadas en hash) son más grandes, pero aún pueden verificarse on-chain con una optimización cuidadosa o posiblemente con algunas suposiciones de confianza (la L2 de StarkWare, por ejemplo, verifica las pruebas STARK en Ethereum mediante un contrato verificador on-chain, aunque con un costo de gas más alto que las SNARKs). La clave es que la cadena no necesita ejecutar el modelo de ML – solo ejecuta una verificación que es mucho más barata que el cómputo original. En resumen, zkML comprime la costosa inferencia de IA en una pequeña prueba que las blockchains (o cualquier verificador) pueden comprobar en milisegundos o segundos.

Lagrange DeepProve: Arquitectura y Rendimiento de un Avance en zkML​

DeepProve de Lagrange Labs es un framework de inferencia zkML de última generación centrado en la velocidad y la escalabilidad. Lanzado en 2025, DeepProve introdujo un nuevo sistema de prueba que es dramáticamente más rápido que las soluciones anteriores como Ezkl. Su diseño se centra en el protocolo de prueba interactivo GKR con sum-check y optimizaciones especializadas para circuitos de redes neuronales. Así es como funciona DeepProve y logra su rendimiento:

• Preprocesamiento Único: Los desarrolladores comienzan con una red neuronal entrenada (los tipos actualmente soportados incluyen perceptrones multicapa y arquitecturas CNN populares). El modelo se exporta al formato ONNX, una representación de grafo estándar. La herramienta de DeepProve luego analiza el modelo ONNX y lo cuantiza (convierte los pesos a formato de punto fijo/entero) para una aritmética de campo eficiente. En esta fase, también genera las claves de prueba y verificación para el protocolo criptográfico. Esta configuración se realiza una vez por modelo y no necesita repetirse por cada inferencia. DeepProve enfatiza la facilidad de integración: “Exporta tu modelo a ONNX → configuración única → genera pruebas → verifica en cualquier lugar”.

• Prueba (Inferencia + Generación de Prueba): Después de la configuración, un probador (que podría ser ejecutado por un usuario, un servicio o la red de probadores descentralizada de Lagrange) toma una nueva entrada $X$ y ejecuta el modelo $M$ sobre ella, obteniendo la salida $Y$. Durante esta ejecución, DeepProve registra una traza de ejecución de los cálculos de cada capa. En lugar de traducir cada multiplicación en un circuito estático por adelantado (como hacen los enfoques SNARK), DeepProve utiliza el protocolo GKR de tiempo lineal para verificar cada capa sobre la marcha. Para cada capa de la red, el probador se compromete con las entradas y salidas de la capa (por ejemplo, a través de hashes criptográficos o compromisos polinómicos) y luego participa en un argumento de sum-check para demostrar que las salidas realmente resultan de las entradas según la función de la capa. El protocolo sum-check convence iterativamente al verificador de la corrección de una suma de evaluaciones de un polinomio que codifica el cálculo de la capa, sin revelar los valores reales. Las operaciones no lineales (como ReLU, softmax) se manejan eficientemente a través de argumentos de búsqueda en DeepProve – si se calculó la salida de una activación, DeepProve puede probar que cada salida corresponde a un par de entrada-salida válido de una tabla precalculada para esa función. Capa por capa, se generan pruebas y luego se agregan en una única prueba sucinta que cubre todo el pase hacia adelante del modelo. El trabajo pesado de la criptografía se minimiza – el probador de DeepProve realiza principalmente cálculos numéricos normales (la inferencia real) más algunos compromisos criptográficos ligeros, en lugar de resolver un sistema gigante de restricciones.

• Verificación: El verificador utiliza la prueba sucinta final junto con algunos valores públicos – típicicamente el identificador comprometido del modelo (un compromiso criptográfico con los pesos de $M$), la entrada $X$ (si no es privada) y la salida declarada $Y$ – para verificar la corrección. La verificación en el sistema de DeepProve implica verificar la transcripción del protocolo sum-check y los compromisos finales de polinomios o hashes. Esto es más complejo que verificar un SNARK clásico (que podría ser unos pocos emparejamientos), pero es vastamente más barato que volver a ejecutar el modelo. En los benchmarks de Lagrange, verificar una prueba de DeepProve para una CNN mediana toma del orden de 0.5 segundos en software. Eso es ~0.5s para confirmar, por ejemplo, que una red convolucional con cientos de miles de parámetros se ejecutó correctamente – más de 500× más rápido que re-computar ingenuamente esa CNN en una GPU para verificación. (De hecho, DeepProve midió una verificación hasta 521× más rápida para CNNs y 671× para MLPs en comparación con la re-ejecución). El tamaño de la prueba es lo suficientemente pequeño como para transmitirlo on-chain (decenas de KB), y la verificación podría realizarse en un contrato inteligente si fuera necesario, aunque 0.5s de cómputo podrían requerir una optimización cuidadosa del gas o una ejecución en capa 2.

Arquitectura y Herramientas: DeepProve está implementado en Rust y proporciona un conjunto de herramientas (la biblioteca zkml) para los desarrolladores. Soporta nativamente los grafos de modelos ONNX, lo que lo hace compatible con modelos de PyTorch o TensorFlow (después de exportarlos). El proceso de prueba actualmente apunta a modelos de hasta unos pocos millones de parámetros (las pruebas incluyen una red densa de 4M de parámetros). DeepProve aprovecha una combinación de componentes criptográficos: un compromiso polinómico multilineal (para comprometerse con las salidas de las capas), el protocolo sum-check para verificar los cálculos y argumentos de búsqueda para operaciones no lineales. Notablemente, el repositorio de código abierto de Lagrange reconoce que se basa en trabajos anteriores (la implementación de sum-check y GKR del proyecto Ceno de Scroll), lo que indica una intersección de zkML con la investigación de rollups de conocimiento cero.

Para lograr escalabilidad en tiempo real, Lagrange combina DeepProve con su Red de Probadores – una red descentralizada de probadores ZK especializados. La generación de pruebas pesadas puede ser delegada a esta red: cuando una aplicación necesita probar una inferencia, envía el trabajo a la red de Lagrange, donde muchos operadores (con staking en EigenLayer para seguridad) calculan las pruebas y devuelven el resultado. Esta red incentiva económicamente la generación de pruebas confiables (los trabajos maliciosos o fallidos resultan en el slashing del operador). Al distribuir el trabajo entre los probadores (y potencialmente aprovechar GPUs o ASICs), la Red de Probadores de Lagrange oculta la complejidad y el costo a los usuarios finales. El resultado es un servicio zkML rápido, escalable y descentralizado: “inferencias de IA verificables, rápidas y asequibles”.

Hitos de Rendimiento: Las afirmaciones de DeepProve están respaldadas por benchmarks contra el estado del arte anterior, Ezkl. Para una CNN con ~264k parámetros (modelo a escala de CIFAR-10), el tiempo de prueba de DeepProve fue de ~1.24 segundos frente a ~196 segundos para Ezkl – aproximadamente 158× más rápido. Para una red densa más grande con 4 millones de parámetros, DeepProve probó una inferencia en ~2.3 segundos frente a ~126.8 segundos para Ezkl (~54× más rápido). Los tiempos de verificación también se redujeron: DeepProve verificó la prueba de la CNN de 264k en ~0.6s, mientras que verificar la prueba de Ezkl (basada en Halo2) tomó más de 5 minutos en CPU en esa prueba. Las mejoras de velocidad provienen de la complejidad casi lineal de DeepProve: su probador escala aproximadamente O(n) con el número de operaciones, mientras que los probadores SNARK basados en circuitos a menudo tienen una sobrecarga superlineal (FFT y compromisos polinómicos que escalan). De hecho, el rendimiento del probador de DeepProve puede estar dentro de un orden de magnitud del tiempo de ejecución de la inferencia simple – los sistemas GKR recientes pueden ser <10× más lentos que la ejecución sin procesar para grandes multiplicaciones de matrices, un logro impresionante en ZK. Esto hace que las pruebas en tiempo real o bajo demanda sean más factibles, allanando el camino para la IA verificable en aplicaciones interactivas.

Casos de Uso: Lagrange ya está colaborando con proyectos de Web3 e IA para aplicar zkML. Los casos de uso de ejemplo incluyen: rasgos de NFT verificables (probar que una evolución generada por IA de un personaje de juego o coleccionable es calculada por el modelo autorizado), procedencia de contenido de IA (probar que una imagen o texto fue generado por un modelo específico, para combatir los deepfakes), modelos de riesgo de DeFi (probar la salida de un modelo que evalúa el riesgo financiero sin revelar datos propietarios), e inferencia de IA privada en salud o finanzas (donde un hospital puede obtener predicciones de IA con una prueba, asegurando la corrección sin exponer los datos del paciente). Al hacer que los resultados de la IA sean verificables y preserven la privacidad, DeepProve abre la puerta a una “IA en la que puedes confiar” en sistemas descentralizados – pasando de una era de “confianza ciega en modelos de caja negra” a una de “garantías objetivas”.

zkML Basado en SNARK: Ezkl y el Enfoque Halo2​

El enfoque tradicional de zkML utiliza zk-SNARKs (Argumentos de Conocimiento Sucintos No Interactivos) para probar la inferencia de redes neuronales. Ezkl (de ZKonduit/Modulus Labs) es un ejemplo líder de este enfoque. Se basa en el sistema de prueba Halo2 (un SNARK de estilo PLONK con compromisos polinómicos sobre BLS12-381). Ezkl proporciona una cadena de herramientas donde un desarrollador puede tomar un modelo de PyTorch o TensorFlow, exportarlo a ONNX, y hacer que Ezkl lo compile en un circuito aritmético personalizado automáticamente.

Cómo funciona: Cada capa de la red neuronal se convierte en restricciones:

• Las capas lineales (densas o de convolución) se convierten en colecciones de restricciones de multiplicación-suma que fuerzan los productos punto entre entradas, pesos y salidas.
• Las capas no lineales (como ReLU, sigmoide, etc.) se manejan mediante búsquedas o restricciones por partes porque tales funciones no son polinómicas. Por ejemplo, una ReLU puede implementarse mediante un selector booleano $b$ con restricciones que aseguren que $y = x \cdot b$ y $0 \le b \le 1$ y $b=1$ si $x>0$ (una forma de hacerlo), o más eficientemente mediante una tabla de búsqueda que mapea $x \mapsto \max(0,x)$ para un rango de valores de $x$. Los argumentos de búsqueda de Halo2 permiten mapear trozos de valores de 16 bits (o más pequeños), por lo que los dominios grandes (como todos los valores de 32 bits) generalmente se “trocean” en varias búsquedas más pequeñas. Este troceado aumenta el número de restricciones.
• Las operaciones con enteros grandes o divisiones (si las hay) se dividen de manera similar en piezas pequeñas. El resultado es un gran conjunto de restricciones R1CS/PLONK adaptadas a la arquitectura específica del modelo.

Ezkl luego utiliza Halo2 para generar una prueba de que estas restricciones se cumplen dadas las entradas secretas (pesos del modelo, entradas privadas) y las salidas públicas. Herramientas e integración: Una ventaja del enfoque SNARK es que aprovecha primitivas bien conocidas. Halo2 ya se utiliza en rollups de Ethereum (por ejemplo, Zcash, zkEVMs), por lo que está probado en batalla y tiene un verificador on-chain fácilmente disponible. Las pruebas de Ezkl utilizan la curva BLS12-381, que Ethereum puede verificar a través de precompilaciones, lo que hace sencillo verificar una prueba de Ezkl en un contrato inteligente. El equipo también ha proporcionado APIs fáciles de usar; por ejemplo, los científicos de datos pueden trabajar con sus modelos en Python y usar la CLI de Ezkl para producir pruebas, sin un conocimiento profundo de los circuitos.

Fortalezas: El enfoque de Ezkl se beneficia de la generalidad y el ecosistema de los SNARKs. Soporta modelos razonablemente complejos y ya ha visto “integraciones prácticas (desde modelos de riesgo de DeFi hasta IA en juegos)”, probando tareas de ML del mundo real. Debido a que opera a nivel del grafo de computación del modelo, puede aplicar optimizaciones específicas de ML: por ejemplo, podar pesos insignificantes o cuantizar parámetros para reducir el tamaño del circuito. También significa que la confidencialidad del modelo es natural – los pesos pueden tratarse como datos de testigo privados, por lo que el verificador solo ve que algún modelo válido produjo la salida, o en el mejor de los casos un compromiso con el modelo. La verificación de las pruebas SNARK es extremadamente rápida (típicamente unos pocos milisegundos o menos on-chain), y los tamaños de las pruebas son pequeños (unos pocos kilobytes), lo cual es ideal para el uso en blockchain.

Debilidades: El rendimiento es el talón de Aquiles. La prueba basada en circuitos impone grandes sobrecargas, especialmente a medida que los modelos crecen. Se ha señalado que, históricamente, los circuitos SNARK podrían requerir un millón de veces más trabajo para el probador que simplemente ejecutar el modelo. Halo2 y Ezkl optimizan esto, pero aún así, operaciones como grandes multiplicaciones de matrices generan toneladas de restricciones. Si un modelo tiene millones de parámetros, el probador debe manejar correspondientemente millones de restricciones, realizando pesadas FFTs y multiexponenciaciones en el proceso. Esto conduce a altos tiempos de prueba (a menudo minutos u horas para modelos no triviales) y un alto uso de memoria. Por ejemplo, probar incluso una CNN relativamente pequeña (por ejemplo, unos pocos cientos de miles de parámetros) puede llevar decenas de minutos con Ezkl en una sola máquina. El equipo detrás de DeepProve citó que Ezkl tardó horas para ciertas pruebas de modelos que DeepProve puede hacer en minutos. Los modelos grandes podrían ni siquiera caber en la memoria o requerir dividirse en múltiples pruebas (que luego necesitan agregación recursiva). Si bien Halo2 está “moderadamente optimizado”, cualquier necesidad de “trocear” búsquedas o manejar operaciones de bits anchos se traduce en una sobrecarga adicional. En resumen, la escalabilidad es limitada – Ezkl funciona bien para modelos pequeños a medianos (y de hecho superó a algunas alternativas anteriores como las VMs ingenuas basadas en Stark en benchmarks), pero tiene dificultades a medida que el tamaño del modelo crece más allá de un punto.

A pesar de estos desafíos, Ezkl y bibliotecas zkML similares basadas en SNARK son importantes peldaños. Demostraron que la inferencia de ML verificada es posible on-chain y tienen un uso activo. Notablemente, proyectos como Modulus Labs demostraron la verificación de un modelo de 18 millones de parámetros on-chain usando SNARKs (con una fuerte optimización). El costo no fue trivial, pero muestra la trayectoria. Además, el Protocolo Mina tiene su propio kit de herramientas zkML que utiliza SNARKs para permitir que los contratos inteligentes en Mina (que están basados en Snark) verifiquen la ejecución de modelos de ML. Esto indica un creciente soporte multiplataforma para zkML basado en SNARK.

Enfoques Basados en STARK: ZK Transparente y Programable para ML​

Los zk-STARKs (Argumentos de Conocimiento Escalables y Transparentes) ofrecen otra ruta hacia zkML. Los STARKs utilizan criptografía basada en hash (como FRI para compromisos polinómicos) y evitan cualquier configuración de confianza. A menudo operan simulando una CPU o VM y probando que la traza de ejecución es correcta. En el contexto de ML, se puede construir un STARK personalizado para la red neuronal o usar una VM STARK de propósito general para ejecutar el código del modelo.

VMs STARK Generales (RISC Zero, Cairo): Un enfoque directo es escribir código de inferencia y ejecutarlo en una VM STARK. Por ejemplo, Risc0 proporciona un entorno RISC-V donde cualquier código (por ejemplo, una implementación en C++ o Rust de una red neuronal) puede ser ejecutado y probado a través de un STARK. De manera similar, el lenguaje Cairo de StarkWare puede expresar cálculos arbitrarios (como una inferencia de LSTM o CNN) que luego son probados por el probador STARK de StarkNet. La ventaja es la flexibilidad – no necesitas diseñar circuitos personalizados para cada modelo. Sin embargo, los primeros benchmarks mostraron que las VMs STARK ingenuas eran más lentas en comparación con los circuitos SNARK optimizados para ML. En una prueba, una prueba basada en Halo2 (Ezkl) fue aproximadamente 3× más rápida que un enfoque basado en STARK en Cairo, e incluso 66× más rápida que una VM STARK RISC-V en un cierto benchmark en 2024. Esta brecha se debe a la sobrecarga de simular cada instrucción de bajo nivel en un STARK y las constantes más grandes en las pruebas STARK (el hashing es rápido pero se necesita mucho; los tamaños de las pruebas STARK son más grandes, etc.). Sin embargo, las VMs STARK están mejorando y tienen el beneficio de una configuración transparente (sin configuración de confianza) y seguridad post-cuántica. A medida que el hardware y los protocolos amigables con STARK avancen, las velocidades de prueba mejorarán.

El enfoque de DeepProve vs STARK: Curiosamente, el uso de GKR y sum-check por parte de DeepProve produce una prueba más parecida a un STARK en espíritu – es una prueba interactiva, basada en hash, sin necesidad de una cadena de referencia estructurada. La contrapartida es que sus pruebas son más grandes y la verificación es más pesada que la de un SNARK. Sin embargo, DeepProve muestra que un diseño de protocolo cuidadoso (especializado en la estructura en capas de ML) puede superar ampliamente tanto a las VMs STARK genéricas como a los circuitos SNARK en tiempo de prueba. Podemos considerar a DeepProve como un probador zkML de estilo STARK a medida (aunque usan el término zkSNARK por brevedad, no tiene la verificación de tamaño constante pequeño de un SNARK tradicional, ya que una verificación de 0.5s es más grande que la verificación típica de un SNARK). Las pruebas STARK tradicionales (como las de StarkNet) a menudo involucran decenas de miles de operaciones de campo para verificar, mientras que un SNARK verifica en quizás unas pocas docenas. Por lo tanto, una contrapartida es evidente: los SNARKs producen pruebas más pequeñas y verificadores más rápidos, mientras que los STARKs (o GKR) ofrecen una escalabilidad más fácil y sin configuración de confianza a costa del tamaño de la prueba y la velocidad de verificación.

Mejoras emergentes: La zkVM JOLT (discutida anteriormente bajo JOLTx) en realidad está produciendo SNARKs (usando compromisos tipo PLONK) pero encarna ideas que también podrían aplicarse en el contexto de STARK (las búsquedas Lasso teóricamente podrían usarse con compromisos FRI). StarkWare y otros están investigando formas de acelerar la prueba de operaciones comunes (como usar puertas personalizadas o pistas en Cairo para operaciones con enteros grandes, etc.). También está Circomlib-ML de Privacy & Scaling Explorations (PSE), que proporciona plantillas de Circom para capas de CNN, etc. – eso está orientado a SNARK, pero conceptualmente se podrían hacer plantillas similares para lenguajes STARK.

En la práctica, los ecosistemas no-Ethereum que aprovechan los STARKs incluyen StarkNet (que podría permitir la verificación on-chain de ML si alguien escribe un verificador, aunque el costo es alto) y el servicio Bonsai de Risc0 (que es un servicio de prueba off-chain que emite pruebas STARK que pueden ser verificadas en varias cadenas). A partir de 2025, la mayoría de las demos de zkML en blockchain han favorecido los SNARKs (debido a la eficiencia del verificador), pero los enfoques STARK siguen siendo atractivos por su transparencia y potencial en entornos de alta seguridad o resistentes a la cuántica. Por ejemplo, una red de cómputo descentralizada podría usar STARKs para permitir que cualquiera verifique el trabajo sin una configuración de confianza, útil para la longevidad. Además, algunas tareas de ML especializadas podrían explotar estructuras amigables con STARK: por ejemplo, los cálculos que usan intensivamente operaciones XOR/bit podrían ser más rápidos en STARKs (ya que son baratos en álgebra booleana y hashing) que en la aritmética de campo de los SNARKs.

Resumen de SNARK vs STARK para ML:

• Rendimiento: Los SNARKs (como Halo2) tienen una enorme sobrecarga de prueba por puerta pero se benefician de potentes optimizaciones y constantes pequeñas para la verificación; los STARKs (genéricos) tienen una sobrecarga constante mayor pero escalan de manera más lineal y evitan criptografía costosa como los emparejamientos. DeepProve muestra que personalizar el enfoque (sum-check) produce un tiempo de prueba casi lineal (rápido) pero con una prueba similar a un STARK. JOLT muestra que incluso una VM general puede hacerse más rápida con un uso intensivo de búsquedas. Empíricamente, para modelos de hasta millones de operaciones: un SNARK bien optimizado (Ezkl) puede manejarlo pero podría tardar decenas de minutos, mientras que DeepProve (GKR) puede hacerlo en segundos. Las VMs STARK en 2024 probablemente estaban en un punto intermedio o peor que los SNARKs a menos que fueran especializadas (Risc0 fue más lento en las pruebas, Cairo fue más lento sin pistas personalizadas).
• Verificación: Las pruebas SNARK se verifican más rápidamente (milisegundos, y datos mínimos on-chain ~ unos pocos cientos de bytes a unos pocos KB). Las pruebas STARK son más grandes (decenas de KB) y tardan más (decenas de ms a segundos) en verificarse debido a muchos pasos de hashing. En términos de blockchain, una verificación de SNARK podría costar, por ejemplo, ~200k de gas, mientras que una verificación de STARK podría costar millones de gas – a menudo demasiado alto para L1, aceptable en L2 o con esquemas de verificación sucintos.
• Configuración y Seguridad: Los SNARKs como Groth16 requieren una configuración de confianza por circuito (poco amigable para modelos arbitrarios), pero los SNARKs universales (PLONK, Halo2) tienen una configuración única que puede reutilizarse para cualquier circuito hasta un cierto tamaño. Los STARKs no necesitan configuración y solo usan suposiciones de hash (más suposiciones de complejidad polinómica clásica), y son seguros post-cuánticos. Esto hace que los STARKs sean atractivos para la longevidad – las pruebas permanecen seguras incluso si surgen las computadoras cuánticas, mientras que los SNARKs actuales (basados en BLS12-381) serían rotos por ataques cuánticos.

Consolidaremos estas diferencias en una tabla comparativa en breve.

FHE para ML (FHE-o-ML): Cómputo Privado vs. Cómputo Verificable​

El Cifrado Totalmente Homomórfico (FHE) es una técnica criptográfica que permite realizar cálculos directamente sobre datos cifrados. En el contexto de ML, FHE puede habilitar una forma de inferencia que preserva la privacidad: por ejemplo, un cliente puede enviar una entrada cifrada a un host de modelo, el host ejecuta la red neuronal sobre el texto cifrado sin descifrarlo, y devuelve un resultado cifrado que el cliente puede descifrar. Esto asegura la confidencialidad de los datos – el propietario del modelo no aprende nada sobre la entrada (y potencialmente el cliente solo aprende la salida, no los detalles internos del modelo si solo obtiene la salida). Sin embargo, FHE por sí solo no produce una prueba de corrección de la misma manera que lo hacen las ZKPs. El cliente debe confiar en que el propietario del modelo realmente realizó el cálculo honestamente (el texto cifrado podría haber sido manipulado). Por lo general, si el cliente tiene el modelo o espera una cierta distribución de salidas, el engaño flagrante puede ser detectado, pero los errores sutiles o el uso de una versión incorrecta del modelo no serían evidentes solo a partir de la salida cifrada.

Compensaciones en el rendimiento: FHE es notoriamente pesado en cómputo. Ejecutar una inferencia de aprendizaje profundo bajo FHE incurre en una ralentización de órdenes de magnitud. Los primeros experimentos (por ejemplo, CryptoNets en 2016) tardaron decenas de segundos en evaluar una pequeña CNN sobre datos cifrados. Para 2024, mejoras como CKKS (para aritmética aproximada) y mejores bibliotecas (Microsoft SEAL, Concrete de Zama) han reducido esta sobrecarga, pero sigue siendo grande. Por ejemplo, un usuario informó que usar Concrete-ML de Zama para ejecutar un clasificador CIFAR-10 tardó 25–30 minutos por inferencia en su hardware. Después de optimizaciones, el equipo de Zama logró ~40 segundos para esa inferencia en un servidor de 192 núcleos. Incluso 40s es extremadamente lento en comparación con una inferencia en texto plano (que podría ser de 0.01s), mostrando una sobrecarga de ~$10^3$–$10^4\times$. Modelos más grandes o mayor precisión aumentan aún más el costo. Además, las operaciones FHE consumen mucha memoria y requieren un bootstrapping ocasional (un paso de reducción de ruido) que es computacionalmente costoso. En resumen, la escalabilidad es un problema importante – el estado del arte de FHE podría manejar una pequeña CNN o una regresión logística simple, pero escalar a grandes CNNs o Transformers está más allá de los límites prácticos actuales.

Ventajas de privacidad: El gran atractivo de FHE es la privacidad de los datos. La entrada puede permanecer completamente cifrada durante todo el proceso. Esto significa que un servidor no confiable puede computar sobre los datos privados de un cliente sin aprender nada sobre ellos. Por el contrario, si el modelo es sensible (propietario), se podría concebir cifrar los parámetros del modelo y hacer que el cliente realice la inferencia FHE de su lado – pero esto es menos común porque si el cliente tiene que hacer el pesado cómputo FHE, niega la idea de delegarlo a un servidor potente. Típicamente, el modelo es público o está en manos del servidor en texto claro, y los datos son cifrados por la clave del cliente. La privacidad del modelo en ese escenario no se proporciona por defecto (el servidor conoce el modelo; el cliente aprende las salidas pero no los pesos). Hay configuraciones más exóticas (como el cómputo seguro de dos partes o FHE de múltiples claves) donde tanto el modelo como los datos pueden mantenerse privados entre sí, pero eso incurre en aún más complejidad. En contraste, zkML a través de ZKPs puede asegurar la privacidad del modelo y la privacidad de los datos a la vez – el probador puede tener tanto el modelo como los datos como testigo secreto, revelando solo lo necesario al verificador.

No se necesita verificación on-chain (y ninguna es posible): Con FHE, el resultado sale cifrado para el cliente. El cliente luego lo descifra para obtener la predicción real. Si queremos usar ese resultado on-chain, el cliente (o quien tenga la clave de descifrado) tendría que publicar el resultado en texto plano y convencer a otros de que es correcto. Pero en ese punto, la confianza vuelve a estar en juego – a menos que se combine con una ZKP. En principio, se podría combinar FHE y ZKP: por ejemplo, usar FHE para mantener los datos privados durante el cómputo, y luego generar una prueba ZK de que el resultado en texto plano corresponde a un cálculo correcto. Sin embargo, combinarlos significa que pagas la penalización de rendimiento de FHE y ZKP – extremadamente impráctico con la tecnología actual. Por lo tanto, en la práctica, FHE-of-ML y zkML sirven para diferentes casos de uso:

• FHE-of-ML: Ideal cuando el objetivo es la confidencialidad entre dos partes (cliente y servidor). Por ejemplo, un servicio en la nube puede alojar un modelo de ML y los usuarios pueden consultarlo con sus datos sensibles sin revelar los datos a la nube (y si el modelo es sensible, quizás desplegarlo a través de codificaciones amigables con FHE). Esto es excelente para servicios de ML que preservan la privacidad (predicciones médicas, etc.). El usuario todavía tiene que confiar en que el servicio ejecute fielmente el modelo (ya que no hay prueba), pero al menos se previene cualquier fuga de datos. Algunos proyectos como Zama incluso están explorando una “EVM habilitada para FHE (fhEVM)” donde los contratos inteligentes podrían operar sobre entradas cifradas, pero verificar esos cálculos on-chain requeriría que el contrato de alguna manera imponga el cálculo correcto – un desafío abierto que probablemente requiera pruebas ZK o hardware seguro especializado.
• zkML (ZKPs): Ideal cuando el objetivo es la verificabilidad y la auditabilidad pública. Si quieres que cualquiera (o cualquier contrato) esté seguro de que “el Modelo $M$ fue evaluado correctamente en $X$ y produjo $Y$”, las ZKPs son la solución. También proporcionan privacidad como un extra (puedes ocultar $X$ o $Y$ o $M$ si es necesario tratándolos como entradas privadas para la prueba), pero su característica principal es la prueba de ejecución correcta.

Una relación complementaria: Vale la pena señalar que las ZKPs protegen al verificador (no aprenden nada sobre los secretos, solo que el cálculo se realizó correctamente), mientras que FHE protege los datos del probador de la parte que computa. En algunos escenarios, estos podrían combinarse – por ejemplo, una red de nodos no confiables podría usar FHE para computar sobre los datos privados de los usuarios y luego proporcionar pruebas ZK a los usuarios (o a la blockchain) de que los cálculos se realizaron de acuerdo con el protocolo. Esto cubriría tanto la privacidad como la corrección, pero el costo de rendimiento es enorme con los algoritmos actuales. Más factibles a corto plazo son los híbridos como Entornos de Ejecución Confiable (TEE) más ZKP o Cifrado Funcional más ZKP – estos están más allá de nuestro alcance, pero apuntan a proporcionar algo similar (los TEEs mantienen los datos/modelo secretos durante el cómputo, luego una ZKP puede certificar que el TEE hizo lo correcto).

En resumen, FHE-of-ML prioriza la confidencialidad de las entradas/salidas, mientras que zkML prioriza la corrección verificable (con posible privacidad). La Tabla 1 a continuación contrasta las propiedades clave:

Enfoque	Rendimiento del Probador (Inferencia y Prueba)	Tamaño de la Prueba y Verificación	Características de Privacidad	¿Configuración de Confianza?	¿Post-Cuántico?
zk-SNARK (Halo2, Groth16, PLONK, etc)	Sobrecarga pesada del probador (hasta 10^6× el tiempo de ejecución normal sin optimizaciones; en la práctica 10^3–10^5×). Optimizado para un modelo/circuito específico; tiempo de prueba en minutos para modelos medianos, horas para grandes. Los SNARKs de zkML recientes (DeepProve con GKR) mejoran esto enormemente (sobrecarga casi lineal, por ejemplo, segundos en lugar de minutos para modelos de millones de parámetros).	Pruebas muy pequeñas (a menudo < 100 KB, a veces ~unos pocos KB). La verificación es rápida: unos pocos emparejamientos o evaluaciones de polinomios (típicamente < 50 ms on-chain). Las pruebas basadas en GKR de DeepProve son más grandes (decenas–cientos de KB) y se verifican en ~0.5 s (aún mucho más rápido que volver a ejecutar el modelo).	Confidencialidad de datos: Sí – las entradas pueden ser privadas en la prueba (no reveladas). Privacidad del modelo: Sí – el probador puede comprometerse con los pesos del modelo y no revelarlos. Ocultación de salida: Opcional – la prueba puede ser de una declaración sin revelar la salida (por ejemplo, “la salida tiene la propiedad P”). Sin embargo, si la salida misma se necesita on-chain, típicamente se vuelve pública. En general, los SNARKs ofrecen flexibilidad completa de conocimiento cero (oculta las partes que quieras).	Depende del esquema. Groth16/EZKL requieren una configuración de confianza por circuito; PLONK/Halo2 usan una configuración universal (una vez). El sum-check GKR de DeepProve es transparente (sin configuración) – una ventaja de ese diseño.	Los SNARKs clásicos (curvas BLS12-381) no son seguros PQ (vulnerables a ataques cuánticos sobre el logaritmo discreto de curvas elípticas). Algunos SNARKs más nuevos usan compromisos seguros PQ, pero Halo2/PLONK como se usan en Ezkl no son seguros PQ. GKR (DeepProve) usa compromisos de hash (por ejemplo, Poseidon/Merkle) que se conjetura son seguros PQ (dependiendo de la resistencia a la preimagen del hash).
zk-STARK (FRI, prueba basada en hash)	La sobrecarga del probador es alta pero con un escalado más lineal. Típicamente 10^2–10^4× más lento que nativo para tareas grandes, con espacio para paralelizar. Las VMs STARK generales (Risc0, Cairo) mostraron un rendimiento más lento vs SNARK para ML en 2024 (por ejemplo, 3×–66× más lento que Halo2 en algunos casos). Los STARKs especializados (o GKR) pueden acercarse a una sobrecarga lineal y superar a los SNARKs para circuitos grandes.	Las pruebas son más grandes: a menudo decenas de KB (creciendo con el tamaño del circuito/log(n)). El verificador debe hacer múltiples comprobaciones de hash y FFT – tiempo de verificación ~O(n^ε) para un ε pequeño (por ejemplo, ~50 ms a 500 ms dependiendo del tamaño de la prueba). On-chain, esto es más costoso (el verificador L1 de StarkWare puede costar millones de gas por prueba). Algunos STARKs soportan pruebas recursivas para comprimir el tamaño, a costa del tiempo del probador.	Privacidad de datos y modelo: Un STARK puede hacerse de conocimiento cero aleatorizando los datos de la traza (agregando cegamiento a las evaluaciones de polinomios), por lo que puede ocultar entradas privadas de manera similar a un SNARK. Muchas implementaciones de STARK se centran en la integridad, pero las variantes zk-STARK sí permiten la privacidad. Así que sí, pueden ocultar entradas/modelos como los SNARKs. Ocultación de salida: igualmente posible en teoría (el probador no declara la salida como pública), pero rara vez se usa ya que usualmente la salida es lo que queremos revelar/verificar.	Sin configuración de confianza. La transparencia es una característica de los STARKs – solo requieren una cadena aleatoria común (que Fiat-Shamir puede derivar). Esto los hace atractivos para un uso abierto (cualquier modelo, en cualquier momento, sin ceremonia por modelo).	Sí, los STARKs se basan en suposiciones de seguridad de hash e información teórica (como el oráculo aleatorio y la dificultad de decodificar ciertas palabras de código en FRI). Se cree que son seguros contra adversarios cuánticos. Por lo tanto, las pruebas STARK son resistentes a PQ, una ventaja para la IA verificable a prueba de futuro.
FHE para ML (Cifrado Totalmente Homomórfico aplicado a la inferencia)	Probador = parte que realiza el cómputo sobre datos cifrados. El tiempo de cómputo es extremadamente alto: 10^3–10^5× más lento que la inferencia en texto plano es común. Hardware de alta gama (servidores de muchos núcleos, FPGA, etc.) puede mitigar esto. Algunas optimizaciones (inferencia de baja precisión, parámetros FHE nivelados) pueden reducir la sobrecarga, pero hay un impacto fundamental en el rendimiento. FHE es actualmente práctico para modelos pequeños o modelos lineales simples; las redes profundas siguen siendo un desafío más allá de tamaños de juguete.	No se genera ninguna prueba. El resultado es una salida cifrada. La verificación en el sentido de comprobar la corrección no es proporcionada por FHE solo – se confía en que la parte que computa no haga trampa. (Si se combina con hardware seguro, se podría obtener una atestación; de lo contrario, un servidor malicioso podría devolver un resultado cifrado incorrecto que el cliente descifraría a una salida errónea sin saber la diferencia).	Confidencialidad de datos: Sí – la entrada está cifrada, por lo que la parte que computa no aprende nada sobre ella. Privacidad del modelo: Si el propietario del modelo está haciendo el cómputo sobre la entrada cifrada, el modelo está en texto plano de su lado (no protegido). Si los roles se invierten (el cliente tiene el modelo cifrado y el servidor computa), el modelo podría mantenerse cifrado, pero este escenario es menos común. Hay técnicas como el ML seguro de dos partes que combinan FHE/MPC para proteger ambos, pero van más allá del FHE simple. Ocultación de salida: Por defecto, la salida del cómputo está cifrada (solo descifrable por la parte con la clave secreta, usualmente el propietario de la entrada). Así que la salida está oculta para el servidor que computa. Si queremos que la salida sea pública, el cliente puede descifrarla y revelarla.	No se necesita configuración. Cada usuario genera su propio par de claves para el cifrado. La confianza se basa en que las claves permanezcan secretas.	La seguridad de los esquemas FHE (por ejemplo, BFV, CKKS, TFHE) se basa en problemas de retículos (Learning With Errors), que se cree que son resistentes a los ataques cuánticos (al menos no se conoce ningún algoritmo cuántico eficiente). Por lo tanto, FHE se considera generalmente seguro post-cuántico.

Tabla 1: Comparación de los enfoques zk-SNARK, zk-STARK y FHE para la inferencia de aprendizaje automático (compensaciones de rendimiento y privacidad).

Casos de Uso e Implicaciones para Aplicaciones Web3​

La convergencia de la IA y la blockchain a través de zkML desbloquea nuevos y potentes patrones de aplicación en Web3:

• Agentes Autónomos Descentralizados y Toma de Decisiones On-Chain: Los contratos inteligentes o las DAOs pueden incorporar decisiones impulsadas por IA con garantías de corrección. Por ejemplo, imagina una DAO que utiliza una red neuronal para analizar las condiciones del mercado antes de ejecutar operaciones. Con zkML, el contrato inteligente de la DAO puede requerir una prueba zkSNARK de que el modelo de ML autorizado (con un compromiso de hash conocido) se ejecutó con los datos más recientes y produjo la acción recomendada, antes de que se acepte la acción. Esto evita que actores maliciosos inyecten una predicción falsa – la cadena verifica el cómputo de la IA. Con el tiempo, incluso se podrían tener agentes autónomos completamente on-chain (contratos que consultan IA off-chain o contienen modelos simplificados) tomando decisiones en DeFi o juegos, con todos sus movimientos probados como correctos y conformes a las políticas a través de pruebas zk. Esto aumenta la confianza en los agentes autónomos, ya que su “pensamiento” es transparente y verificable en lugar de una caja negra.

• Mercados de Cómputo Verificable: Proyectos como Lagrange están creando efectivamente mercados de computación verificable – los desarrolladores pueden externalizar la inferencia de ML pesada a una red de probadores y recibir a cambio una prueba con el resultado. Esto es análogo a la computación en la nube descentralizada, pero con confianza incorporada: no necesitas confiar en el servidor, solo en la prueba. Es un cambio de paradigma para los oráculos y la computación off-chain. Protocolos como la próxima DSC (capa de secuenciación descentralizada) de Ethereum o las redes de oráculos podrían usar esto para proporcionar fuentes de datos o análisis con garantías criptográficas. Por ejemplo, un oráculo podría suministrar “el resultado del modelo X en la entrada Y” y cualquiera puede verificar la prueba adjunta on-chain, en lugar de confiar en la palabra del oráculo. Esto podría habilitar IA-como-servicio verificable en la blockchain: cualquier contrato puede solicitar un cómputo (como “califica estos riesgos crediticios con mi modelo privado”) y aceptar la respuesta solo con una prueba válida. Proyectos como Gensyn están explorando mercados de entrenamiento e inferencia descentralizados utilizando estas técnicas de verificación.

• NFTs y Juegos – Procedencia y Evolución: En los juegos de blockchain o coleccionables NFT, zkML puede probar que los rasgos o movimientos del juego fueron generados por modelos de IA legítimos. Por ejemplo, un juego podría permitir que una IA evolucione los atributos de una mascota NFT. Sin ZK, un usuario astuto podría modificar la IA o el resultado para obtener una mascota superior. Con zkML, el juego puede requerir una prueba de que “las nuevas estadísticas de la mascota fueron calculadas por el modelo de evolución oficial sobre las estadísticas antiguas de la mascota”, evitando trampas. De manera similar para los NFTs de arte generativo: un artista podría lanzar un modelo generativo como un compromiso; más tarde, al acuñar NFTs, probar que cada imagen fue producida por ese modelo dada una semilla, garantizando la autenticidad (e incluso haciéndolo sin revelar el modelo exacto al público, preservando la propiedad intelectual del artista). Esta verificación de procedencia asegura la autenticidad de una manera similar a la aleatoriedad verificable – excepto que aquí es creatividad verificable.

• IA que Preserva la Privacidad en Dominios Sensibles: zkML permite la confirmación de resultados sin exponer las entradas. En el sector de la salud, los datos de un paciente podrían ser procesados por un modelo de diagnóstico de IA por un proveedor de la nube; el hospital recibe un diagnóstico y una prueba de que el modelo (que podría ser propiedad privada de una compañía farmacéutica) se ejecutó correctamente sobre los datos del paciente. Los datos del paciente permanecen privados (solo se usó una forma cifrada o comprometida en la prueba), y los pesos del modelo permanecen propietarios – sin embargo, el resultado es confiable. Los reguladores o las aseguradoras también podrían verificar que solo se usaron modelos aprobados. En finanzas, una empresa podría demostrar a un auditor o regulador que su modelo de riesgo se aplicó a sus datos internos y produjo ciertas métricas sin revelar los datos financieros sensibles subyacentes. Esto permite el cumplimiento y la supervisión con garantías criptográficas en lugar de confianza manual.

• Interoperabilidad Cross-Chain y Off-Chain: Debido a que las pruebas de conocimiento cero son fundamentalmente portátiles, zkML puede facilitar resultados de IA cross-chain. Una cadena podría tener una aplicación intensiva en IA ejecutándose off-chain; puede publicar una prueba del resultado en una blockchain diferente, que lo aceptará sin necesidad de confianza. Por ejemplo, considera una DAO multi-cadena que utiliza una IA para agregar el sentimiento en las redes sociales (datos off-chain). El análisis de IA (NLP complejo sobre grandes datos) se realiza off-chain por un servicio que luego publica una prueba en una pequeña blockchain (o múltiples cadenas) de que “el análisis se realizó correctamente y la puntuación de sentimiento de salida = 0.85”. Todas las cadenas pueden verificar y usar ese resultado en su lógica de gobernanza, sin que cada una necesite volver a ejecutar el análisis. Este tipo de cómputo verificable interoperable es lo que la red de Lagrange pretende soportar, sirviendo a múltiples rollups o L1s simultáneamente. Elimina la necesidad de puentes confiables o suposiciones de oráculos al mover resultados entre cadenas.

• Alineación y Gobernanza de la IA: En una nota más prospectiva, zkML ha sido destacado como una herramienta para la gobernanza y seguridad de la IA. Las declaraciones de visión de Lagrange, por ejemplo, argumentan que a medida que los sistemas de IA se vuelven más poderosos (incluso superinteligentes), la verificación criptográfica será esencial para asegurar que sigan las reglas acordadas. Al requerir que los modelos de IA produzcan pruebas de su razonamiento o restricciones, los humanos retienen un grado de control – “no puedes confiar en lo que no puedes verificar”. Si bien esto es especulativo e involucra tanto aspectos sociales como técnicos, la tecnología podría hacer cumplir que un agente de IA que se ejecuta de forma autónoma todavía demuestre que está utilizando un modelo aprobado y que no ha sido manipulado. Las redes de IA descentralizadas podrían usar pruebas on-chain para verificar las contribuciones (por ejemplo, una red de nodos que entrena colaborativamente un modelo puede probar que cada actualización se calculó fielmente). Por lo tanto, zkML podría desempeñar un papel en asegurar que los sistemas de IA sigan siendo responsables ante los protocolos definidos por humanos, incluso en entornos descentralizados o no controlados.

En conclusión, zkML y la IA verificable on-chain representan una convergencia de la criptografía avanzada y el aprendizaje automático que promete mejorar la confianza, la transparencia y la privacidad en las aplicaciones de IA. Al comparar los principales enfoques – zk-SNARKs, zk-STARKs y FHE – vemos un espectro de compensaciones entre rendimiento y privacidad, cada uno adecuado para diferentes escenarios. Los frameworks basados en SNARK como Ezkl y las innovaciones como DeepProve de Lagrange han hecho factible probar inferencias sustanciales de redes neuronales con un esfuerzo práctico, abriendo la puerta a implementaciones en el mundo real de IA verificable. Los enfoques basados en STARK y VM prometen una mayor flexibilidad y seguridad post-cuántica, que se volverán importantes a medida que el campo madure. FHE, aunque no es una solución para la verificabilidad, aborda la necesidad complementaria de la computación de ML confidencial, y en combinación con ZKPs o en contextos privados específicos puede empoderar a los usuarios para aprovechar la IA sin sacrificar la privacidad de los datos.

Las implicaciones para Web3 son significativas: podemos prever contratos inteligentes reaccionando a predicciones de IA, sabiendo que son correctas; mercados de cómputo donde los resultados se venden sin confianza; identidades digitales (como la prueba de humanidad de Worldcoin a través de IA de iris) protegidas por zkML para confirmar que alguien es humano sin filtrar su imagen biométrica; y en general una nueva clase de “inteligencia demostrable” que enriquece las aplicaciones de blockchain. Quedan muchos desafíos – rendimiento para modelos muy grandes, ergonomía para desarrolladores y la necesidad de hardware especializado – pero la trayectoria es clara. Como señaló un informe, “las ZKPs de hoy pueden soportar modelos pequeños, pero los modelos de moderados a grandes rompen el paradigma”; sin embargo, los rápidos avances (mejoras de velocidad de 50×–150× con DeepProve sobre el estado del arte anterior) están empujando ese límite hacia afuera. Con la investigación en curso (por ejemplo, sobre aceleración de hardware y prueba distribuida), podemos esperar que modelos de IA progresivamente más grandes y complejos se vuelvan demostrables. zkML podría evolucionar pronto de demos de nicho a un componente esencial de la infraestructura de IA confiable, asegurando que a medida que la IA se vuelve ubicua, lo haga de una manera que sea auditable, descentralizada y alineada con la privacidad y seguridad del usuario.

ETHDenver 2025, bajo la marca del “Año de los Regenerados”, consolidó su estatus como una de las mayores reuniones de Web3 del mundo. Abarcando la BUIDLWeek (23–26 de febrero), el Evento Principal (27 de febrero–2 de marzo) y un Retiro en la Montaña post-conferencia, el festival atrajo a una cifra esperada de más de 25,000 participantes. Constructores, desarrolladores, inversores y creativos de más de 125 países convergieron en Denver para celebrar el ethos de descentralización e innovación de Ethereum. Fiel a sus raíces comunitarias, ETHDenver siguió siendo de asistencia gratuita, financiado por la comunidad y repleto de contenido: desde hackatones y talleres hasta paneles, eventos de presentación y fiestas. La historia del evento sobre los “Regenerados” defendiendo la descentralización estableció un tono que enfatizaba los bienes públicos y la construcción colaborativa, incluso en medio de un panorama tecnológico competitivo. El resultado fue una semana de actividad de construcción de alta energía y discusiones con visión de futuro, ofreciendo una instantánea de las tendencias emergentes de Web3 y perspectivas accionables para los profesionales de la industria.

Tendencias emergentes de Web3 destacadas por los ponentes​

Ninguna narrativa única dominó ETHDenver 2025; en su lugar, un amplio espectro de tendencias Web3 tomó el protagonismo. A diferencia del año pasado (cuando el restaking a través de EigenLayer se robó el espectáculo), la agenda de 2025 fue un poco de todo: desde redes de infraestructura física descentralizada (DePIN) hasta agentes de IA, desde el cumplimiento normativo hasta la tokenización de activos del mundo real (RWA), además de privacidad, interoperabilidad y más. De hecho, el fundador de ETHDenver, John Paller, abordó las preocupaciones sobre el contenido multicadena señalando que “más del 95 % de nuestros patrocinadores y el 90 % del contenido está alineado con ETH/EVM”; sin embargo, la presencia de ecosistemas no pertenecientes a Ethereum subrayó la interoperabilidad como un tema clave. Los principales ponentes reflejaron estas áreas de tendencia: por ejemplo, el escalado con zk-rollup y Capa 2 fue destacado por Alex Gluchowski (CEO de Matter Labs/zkSync), mientras que la innovación multicadena provino de Adeniyi Abiodun de Mysten Labs (Sui) y Albert Chon de Injective.

La convergencia de la IA y Web3 surgió como una fuerte corriente subyacente. Numerosas charlas y eventos paralelos se centraron en agentes de IA descentralizados y cruces entre “DeFi e IA”. Un Día del Agente de IA dedicado mostró demostraciones de IA on-chain, y un colectivo de 14 equipos (incluido el kit de desarrollador de Coinbase y la unidad de IA de NEAR) incluso anunció la Open Agents Alliance (OAA), una iniciativa para proporcionar acceso a IA sin permisos y gratuito mediante la agrupación de infraestructura Web3. Esto indica un creciente interés en agentes autónomos y dApps impulsadas por IA como una nueva frontera para los constructores. De la mano de la IA, DePIN (infraestructura física descentralizada) fue otra palabra de moda: múltiples paneles (p. ej., Día de DePIN, Cumbre DePIN) exploraron proyectos que conectan la blockchain con redes físicas (desde telecomunicaciones hasta movilidad).

Cuckoo AI Network causó sensación en ETHDenver 2025, presentando su innovador mercado descentralizado de servicio de modelos de IA diseñado para creadores y desarrolladores. Con una presencia convincente tanto en el hackatón como en los eventos paralelos liderados por la comunidad, Cuckoo AI atrajo una atención significativa de los desarrolladores intrigados por su capacidad para monetizar recursos de GPU/CPU e integrar fácilmente APIs de IA on-chain. Durante su taller dedicado y sesión de networking, Cuckoo AI destacó cómo la infraestructura descentralizada podría democratizar eficientemente el acceso a servicios avanzados de IA. Esto se alinea directamente con las tendencias más amplias del evento, particularmente la intersección de la blockchain con la IA, DePIN y la financiación de bienes públicos. Para los inversores y desarrolladores en ETHDenver, Cuckoo AI surgió como un claro ejemplo de cómo los enfoques descentralizados pueden impulsar la próxima generación de dApps e infraestructura impulsadas por IA, posicionándose como una atractiva oportunidad de inversión dentro del ecosistema Web3.

La privacidad, la identidad y la seguridad siguieron siendo prioritarias. Los ponentes y talleres abordaron temas como las pruebas de conocimiento cero (la presencia de zkSync), la gestión de la identidad y las credenciales verificables (una categoría dedicada de Privacidad y Seguridad en el hackatón), y cuestiones legales/regulatorias (una cumbre legal on-chain formó parte de las pistas del festival). Otra discusión notable fue el futuro de la recaudación de fondos y la descentralización de la financiación: un debate en el Escenario Principal entre Haseeb Qureshi de Dragonfly Capital y Matt O’Connor de Legion (una plataforma “similar a las ICO”) sobre ICOs frente a la financiación de VC cautivó a los asistentes. Este debate destacó modelos emergentes como las ventas de tokens comunitarias que desafían las rutas tradicionales de VC, una tendencia importante para las startups de Web3 que navegan la obtención de capital. La conclusión para los profesionales es clara: Web3 en 2025 es multidisciplinario, abarcando finanzas, IA, activos reales y cultura, y mantenerse informado significa mirar más allá de cualquier ciclo de sobreexpectación para ver el espectro completo de la innovación.

Patrocinadores y sus áreas de enfoque estratégico​

La lista de patrocinadores de ETHDenver en 2025 parece un quién es quién de las capas 1, capas 2 y proyectos de infraestructura Web3, cada uno aprovechando el evento para avanzar en sus objetivos estratégicos. Los protocolos de cadena cruzada y multicadena tuvieron una fuerte presencia. Por ejemplo, Polkadot fue uno de los principales patrocinadores con un considerable fondo de recompensas de 80,000 $, incentivando a los constructores a crear DApps y appchains de cadena cruzada. De manera similar, **BNB Chain, Flow, Hedera y Base (la L2 de Coinbase)** ofrecieron cada uno hasta 50,000$ para proyectos que se integraran con sus ecosistemas, señalando su impulso para atraer a los desarrolladores de Ethereum. Incluso ecosistemas tradicionalmente separados como Solana e Internet Computer se unieron con desafíos patrocinados (p. ej., Solana coorganizó un evento de DePIN, e Internet Computer ofreció una recompensa de “Solo posible en ICP”). Esta presencia interecosistémica generó cierto escrutinio de la comunidad, pero el equipo de ETHDenver señaló que la gran mayoría del contenido permaneció alineado con Ethereum. El efecto neto fue que la interoperabilidad se convirtió en un tema central: los patrocinadores buscaron posicionar sus plataformas como extensiones complementarias del universo Ethereum.

Las soluciones de escalado y los proveedores de infraestructura también estuvieron en primer plano. Las principales L2 de Ethereum como Optimism y Arbitrum tuvieron grandes stands y desafíos patrocinados (las recompensas de Optimism llegaron hasta los 40,000 $), reforzando su enfoque en incorporar desarrolladores a los rollups. Nuevos participantes como **ZkSync y Zircuit** (un proyecto que muestra un enfoque de rollup L2) enfatizaron la tecnología de conocimiento cero e incluso contribuyeron con SDKs (ZkSync promovió su SDK Smart Sign-On para un inicio de sesión fácil de usar, que los equipos del hackatón utilizaron con entusiasmo). El **restaking y la infraestructura de blockchain modular** fue otro interés de los patrocinadores: **EigenLayer** (pionero en el restaking) tuvo su propia categoría de 50,000$ e incluso coorganizó un evento sobre “Restaking y DeFAI (IA Descentralizada)”, combinando su modelo de seguridad con temas de IA. Los oráculos y el middleware de interoperabilidad estuvieron representados por empresas como Chainlink y Wormhole, cada una emitiendo recompensas por usar sus protocolos.

Notablemente, las aplicaciones de consumo y herramientas de Web3 contaron con el apoyo de patrocinadores para mejorar la experiencia del usuario. La presencia de Uniswap, con uno de los stands más grandes, no fue solo para exhibirse: el gigante de DeFi utilizó el evento para anunciar nuevas funciones de billetera como rampas de salida de fiat integradas, alineándose con su enfoque de patrocinio en la usabilidad de DeFi. Plataformas centradas en la identidad y la comunidad como Galxe (Gravity) y Lens Protocol patrocinaron desafíos en torno a las redes sociales y credenciales on-chain. Incluso las empresas tecnológicas tradicionales mostraron interés: PayPal y Google Cloud organizaron un happy hour sobre stablecoins y pagos para discutir el futuro de los pagos en cripto. Esta mezcla de patrocinadores muestra que los intereses estratégicos abarcaron desde la infraestructura central hasta las aplicaciones para el usuario final, todos convergiendo en ETHDenver para proporcionar recursos (APIs, SDKs, subvenciones) a los desarrolladores. Para los profesionales de Web3, el fuerte patrocinio de las capas 1, capas 2 e incluso de las fintechs de Web2 destaca dónde está invirtiendo la industria: interoperabilidad, escalabilidad, seguridad y hacer que las criptomonedas sean útiles para la próxima ola de usuarios.

Lo más destacado del hackatón: Proyectos innovadores y ganadores​

En el corazón de ETHDenver se encuentra su legendario #BUIDLathon, un hackatón que ha crecido hasta convertirse en el hackatón de blockchain más grande del mundo con miles de desarrolladores. En 2025, el hackatón ofreció una bolsa de premios récord de más de 1,043,333 $ para impulsar la innovación. Las recompensas de más de 60 patrocinadores se dirigieron a dominios clave de Web3, dividiendo la competencia en categorías como: DeFi e IA, NFTs y Gaming, Infraestructura y Escalabilidad, Privacidad y Seguridad, y DAOs y Bienes Públicos. El diseño de estas categorías es revelador en sí mismo; por ejemplo, emparejar DeFi con IA sugiere el surgimiento de aplicaciones financieras impulsadas por IA, mientras que una categoría dedicada a Bienes Públicos reafirma el enfoque de la comunidad en las finanzas regenerativas y el desarrollo de código abierto. Cada categoría fue respaldada por patrocinadores que ofrecían premios por el mejor uso de su tecnología (p. ej., Polkadot y Uniswap para DeFi, Chainlink para interoperabilidad, Optimism para soluciones de escalado). Los organizadores incluso implementaron la votación cuadrática para la evaluación, permitiendo que la comunidad ayudara a destacar los mejores proyectos, con los ganadores finales elegidos por jueces expertos.

El resultado fue una avalancha de proyectos de vanguardia, muchos de los cuales ofrecen un vistazo al futuro de Web3. Entre los ganadores notables se incluyó un juego multijugador on-chain “0xCaliber”, un shooter en primera persona que ejecuta interacciones de blockchain en tiempo real dentro de un juego FPS clásico. 0xCaliber impresionó a los jueces al demostrar un verdadero gaming on-chain: los jugadores compran su entrada con cripto, “disparan” balas on-chain y usan trucos de cadena cruzada para recolectar y cobrar el botín, todo en tiempo real. Este tipo de proyecto muestra la creciente madurez del gaming Web3 (integrando motores de juego como Unity con contratos inteligentes) y la creatividad en la fusión del entretenimiento con la criptoeconomía. Otra categoría de hacks destacados fue la que fusionaba IA con Ethereum: los equipos construyeron plataformas de “agentes” que usan contratos inteligentes para coordinar servicios de IA, inspirados por el anuncio de la Open Agents Alliance. Por ejemplo, un proyecto del hackatón integró auditores de contratos inteligentes impulsados por IA (generando automáticamente casos de prueba de seguridad para contratos), alineándose con la tendencia de IA descentralizada observada en la conferencia.

Los proyectos de infraestructura y herramientas también fueron prominentes. Algunos equipos abordaron la abstracción de cuentas y la experiencia del usuario, utilizando kits de herramientas de patrocinadores como el Smart Sign-On de zkSync para crear flujos de inicio de sesión sin billetera para dApps. Otros trabajaron en puentes de cadena cruzada e integraciones de Capa 2, reflejando el continuo interés de los desarrolladores en la interoperabilidad. En la categoría de Bienes Públicos y DAO, algunos proyectos abordaron el impacto social en el mundo real, como una dApp para identidad descentralizada y ayuda para personas sin hogar (aprovechando NFTs y fondos comunitarios, una idea que recuerda a hacks de ReFi anteriores). Los conceptos de finanzas regenerativas (ReFi), como la financiación de bienes públicos a través de mecanismos novedosos, continuaron apareciendo, haciendo eco del tema regenerativo de ETHDenver.

Aunque los ganadores finales se celebraron al final del evento principal, el verdadero valor residía en la cantera de innovación: se recibieron más de 400 presentaciones de proyectos, muchos de los cuales seguirán vivos más allá del evento. El hackatón de ETHDenver tiene un historial de sembrar futuras startups (de hecho, algunos proyectos pasados del BUIDLathon se han convertido en patrocinadores). Para inversores y tecnólogos, el hackatón proporcionó una ventana a las ideas más innovadoras, señalando que la próxima ola de startups de Web3 podría surgir en áreas como el gaming on-chain, las dApps con infusión de IA, la infraestructura de cadena cruzada y las soluciones dirigidas al impacto social. Con casi 1 millón de dólares en recompensas distribuidas a los desarrolladores, los patrocinadores demostraron su compromiso con hechos para cultivar estas innovaciones.

Eventos de networking e interacciones con inversores​

ETHDenver no se trata solo de escribir código, sino también de hacer contactos. En 2025, el festival potenció el networking con eventos tanto formales como informales diseñados para startups, inversores y constructores de comunidades. Un evento destacado fue el Startup Rodeo de Bufficorn Ventures (BV), una exhibición de alta energía donde 20 startups seleccionadas presentaron sus demos a inversores en una exposición al estilo de una feria de ciencias. Celebrado el 1 de marzo en el salón principal, el Startup Rodeo fue descrito más como “citas rápidas” que como un concurso de pitches: los fundadores atendían mesas para presentar sus proyectos uno a uno mientras todos los inversores asistentes recorrían el recinto. Este formato aseguró que incluso los equipos en etapas tempranas pudieran conseguir tiempo de calidad cara a cara con VCs, socios estratégicos o colaboradores. Muchas startups usaron esto como una plataforma de lanzamiento para encontrar clientes y financiación, aprovechando la presencia concentrada de fondos de Web3 en ETHDenver.

En el último día de la conferencia, el BV BuffiTank Pitchfest tomó el protagonismo en el escenario principal: una competencia de pitches más tradicional con 10 de las startups en etapa inicial “más innovadoras” de la comunidad de ETHDenver. Estos equipos (distintos de los ganadores del hackatón) presentaron sus modelos de negocio a un panel de VCs de primer nivel y líderes de la industria, compitiendo por reconocimientos y posibles ofertas de inversión. El Pitchfest ilustró el papel de ETHDenver como un generador de oportunidades de negocio: estaba explícitamente dirigido a equipos “ya organizados... en busca de inversión, clientes y exposición”, especialmente aquellos conectados a la comunidad de SporkDAO. La recompensa para los ganadores no fue un simple premio en efectivo, sino la promesa de unirse al portafolio de Bufficorn Ventures u otras cohortes de aceleradoras. En esencia, ETHDenver creó su propio mini “Shark Tank” para Web3, catalizando la atención de los inversores sobre los mejores proyectos de la comunidad.

Más allá de estas exhibiciones oficiales, la semana estuvo repleta de eventos de networking para inversores y fundadores. Según una guía curada por Belong, entre los eventos paralelos notables se incluyó un “Meet the VCs” Happy Hour organizado por CertiK Ventures el 27 de febrero, un StarkNet VC & Founders Lounge el 1 de marzo, e incluso eventos informales como un evento de pitches temático de golf “Pitch & Putt”. Estas reuniones proporcionaron entornos relajados para que los fundadores se codearan con capitalistas de riesgo, lo que a menudo conducía a reuniones de seguimiento después de la conferencia. La presencia de muchas firmas de VC emergentes también se sintió en los paneles; por ejemplo, una sesión en el EtherKnight Stage destacó nuevos fondos como Reflexive Capital, Reforge VC, Topology, Metalayer y Hash3 y qué tendencias les entusiasman más. Las primeras indicaciones sugieren que estos VCs estaban interesados en áreas como las redes sociales descentralizadas, la IA y la nueva infraestructura de Capa 1 (cada fondo buscando un nicho para diferenciarse en un panorama de VC competitivo).

Para los profesionales que buscan capitalizar el networking de ETHDenver: la conclusión clave es el valor de los eventos paralelos y los encuentros específicos. Los acuerdos y las asociaciones a menudo germinan durante un café o un cóctel en lugar de en el escenario. La miríada de eventos para inversores de ETHDenver 2025 demuestra que la comunidad de financiación de Web3 está buscando activamente talento e ideas, incluso en un mercado austero. Las startups que llegaron preparadas con demos pulidas y una propuesta de valor clara (a menudo aprovechando el impulso del hackatón del evento) encontraron audiencias receptivas. Mientras tanto, los inversores utilizaron estas interacciones para medir el pulso de la comunidad de desarrolladores: ¿qué problemas están resolviendo los constructores más brillantes este año? En resumen, ETHDenver reforzó que el networking es tan importante como el BUIDLing: es un lugar donde un encuentro casual puede conducir a una inversión semilla o donde una conversación perspicaz puede encender la próxima gran colaboración.

Tendencias de capital de riesgo y oportunidades de inversión en Web3​

Una narrativa sutil pero importante a lo largo de ETHDenver 2025 fue el panorama en evolución del propio capital de riesgo en Web3. A pesar de los altibajos del mercado cripto en general, los inversores en ETHDenver mostraron un fuerte apetito por proyectos prometedores de Web3. Reporteros de Blockworks en el terreno notaron “cuánto capital privado sigue fluyendo hacia las criptomonedas, sin dejarse intimidar por los vientos en contra macroeconómicos”, con valoraciones en la etapa semilla a menudo por las nubes para las ideas más candentes. De hecho, la gran cantidad de VCs presentes, desde fondos nativos de cripto hasta inversores tecnológicos tradicionales incursionando en Web3, dejó claro que ETHDenver sigue siendo un centro de negociaciones.

Se podían discernir enfoques temáticos emergentes a partir de lo que los VCs discutían y patrocinaban. La prevalencia del contenido de IA x Cripto (categorías de hackatón, paneles, etc.) no fue solo una tendencia de desarrolladores; refleja el interés de los inversores en el nexo “DeFi se encuentra con la IA”. Muchos inversores están observando startups que aprovechan el aprendizaje automático o los agentes autónomos en la blockchain, como lo demuestran las hackhouses y cumbres de IA patrocinadas por VCs. De manera similar, el fuerte enfoque en DePIN y la tokenización de activos del mundo real (RWA) indica que los fondos ven oportunidades en proyectos que conectan la blockchain con activos de la economía real y dispositivos físicos. El dedicado Día de RWA (26 de febrero), un evento B2B sobre el futuro de los activos tokenizados, sugiere que los cazatalentos de riesgo están buscando activamente en esa arena al próximo Goldfinch o Centrifuge (es decir, plataformas que llevan las finanzas del mundo real a la cadena).

Otra tendencia observable fue una creciente experimentación con modelos de financiación. El debate mencionado sobre ICOs vs VCs no fue solo teatro de conferencia; refleja un movimiento real en el capital de riesgo hacia una financiación más centrada en la comunidad. Algunos VCs en ETHDenver indicaron estar abiertos a modelos híbridos (p. ej., lanzamientos de tokens respaldados por VCs que involucran a la comunidad en las primeras rondas). Además, la financiación de bienes públicos e inversión de impacto tuvo un lugar en la mesa. Con el ethos de regeneración de ETHDenver, incluso los inversores discutieron cómo apoyar la infraestructura de código abierto y a los desarrolladores a largo plazo, más allá de simplemente perseguir el próximo boom de DeFi o NFT. Paneles como “Financiando el Futuro: Modelos en Evolución para Startups Onchain” exploraron alternativas como subvenciones, inversiones de tesorerías de DAO y financiación cuadrática para complementar el dinero tradicional de VC. Esto apunta a una industria que madura en cómo se capitalizan los proyectos: una mezcla de capital de riesgo, fondos de ecosistema y financiación comunitaria trabajando en conjunto.

Desde el punto de vista de las oportunidades, los profesionales e inversores de Web3 pueden extraer algunas perspectivas accionables de la dinámica de riesgo de ETHDenver: (1) La infraestructura sigue siendo el rey: muchos VCs expresaron que el sector de 'picos y palas' (escalado L2, seguridad, herramientas de desarrollo) sigue siendo una inversión de alto valor como la columna vertebral de la industria. (2) Nuevas verticales como la convergencia IA/blockchain y DePIN son fronteras de inversión emergentes: ponerse al día en estas áreas o encontrar startups allí podría ser gratificante. (3) Los proyectos impulsados por la comunidad y los bienes públicos podrían ver una financiación novedosa: los inversores inteligentes están descubriendo cómo apoyarlos de manera sostenible (por ejemplo, invirtiendo en protocolos que permiten la gobernanza descentralizada o la propiedad compartida). En general, ETHDenver 2025 demostró que, si bien el panorama de riesgo de Web3 es competitivo, está rebosante de convicción: hay capital disponible para aquellos que construyen el futuro de DeFi, NFTs, gaming y más, e incluso las ideas nacidas en el mercado bajista pueden encontrar respaldo si apuntan a la tendencia correcta.

Recursos para desarrolladores, kits de herramientas y sistemas de apoyo​

ETHDenver siempre ha estado enfocado en los constructores, y 2025 no fue la excepción: funcionó como una conferencia de desarrolladores de código abierto con una plétora de recursos y apoyo para los desarrolladores de Web3. Durante la BUIDLWeek, los asistentes tuvieron acceso a talleres en vivo, bootcamps técnicos y mini-cumbres que abarcaban diversos dominios. Por ejemplo, los desarrolladores podían unirse a una Cumbre de Tecnología de Vanguardia para experimentar con los últimos protocolos, o asistir a una Cumbre Legal On-Chain para aprender sobre el desarrollo de contratos inteligentes conformes a la ley. Los principales patrocinadores y equipos de blockchain realizaron sesiones prácticas: el equipo de Polkadot organizó hacker houses y talleres sobre cómo lanzar parachains; EigenLayer dirigió un “bootcamp de restaking” para enseñar a los desarrolladores a aprovechar su capa de seguridad; Polygon y zkSync ofrecieron tutoriales sobre la construcción de dApps escalables con tecnología de conocimiento cero. Estas sesiones proporcionaron un invaluable tiempo cara a cara con los ingenieros principales, permitiendo a los desarrolladores obtener ayuda con la integración y aprender nuevos kits de herramientas de primera mano.

A lo largo del evento principal, el recinto contó con un #BUIDLHub y Makerspace dedicados donde los constructores podían codificar en un entorno colaborativo y acceder a mentores. Los organizadores de ETHDenver publicaron una detallada Guía BUIDLer y facilitaron un programa de mentoría en el lugar (expertos de los patrocinadores estaban disponibles para desbloquear a los equipos en problemas técnicos). Las empresas de herramientas para desarrolladores también estuvieron presentes en masa, desde Alchemy e Infura (para APIs de blockchain) hasta Hardhat y Foundry (para el desarrollo de contratos inteligentes). Muchas revelaron nuevos lanzamientos o herramientas beta en el evento. Por ejemplo, el equipo de MetaMask presentó una importante actualización de la billetera con abstracción de gas y un SDK mejorado para desarrolladores de dApps, con el objetivo de simplificar cómo las aplicaciones cubren las tarifas de gas para los usuarios. Varios proyectos lanzaron SDKs o bibliotecas de código abierto: se introdujeron el “Agent Kit” de Coinbase para agentes de IA y el kit de herramientas colaborativo de la Open Agents Alliance, y Story.xyz promovió su SDK Story para el licenciamiento de propiedad intelectual on-chain durante su propio evento de hackatón.

Las recompensas y el apoyo a los hackers aumentaron aún más la experiencia del desarrollador. Con más de 180 recompensas ofrecidas por 62 patrocinadores, los hackers tenían efectivamente un menú de desafíos específicos para elegir, cada uno con documentación, horas de consulta y, a veces, entornos de prueba personalizados (sandboxes). Por ejemplo, la recompensa de Optimism desafiaba a los desarrolladores a usar los últimos opcodes de Bedrock (con sus ingenieros disponibles para ayudar), y el desafío de Uniswap proporcionaba acceso a su nueva API para la integración de rampas de salida. Herramientas de coordinación y aprendizaje, como la aplicación móvil oficial de ETHDenver y los canales de Discord, mantuvieron a los desarrolladores informados sobre cambios de horario, misiones secundarias e incluso oportunidades de trabajo a través de la bolsa de trabajo de ETHDenver.

Un recurso notable fue el énfasis en los experimentos de financiación cuadrática y la votación on-chain. ETHDenver integró un sistema de votación cuadrática para la evaluación del hackatón, exponiendo a muchos desarrolladores al concepto. Además, la presencia de Gitcoin y otros grupos de bienes públicos significó que los desarrolladores podían aprender sobre la financiación de subvenciones para sus proyectos después del evento. En resumen, ETHDenver 2025 equipó a los desarrolladores con herramientas de vanguardia (SDKs, APIs), orientación experta y apoyo de seguimiento para continuar sus proyectos. Para los profesionales de la industria, es un recordatorio de que nutrir a la comunidad de desarrolladores, a través de la educación, las herramientas y la financiación, es fundamental. Muchos de los recursos destacados (como nuevos SDKs o entornos de desarrollo mejorados) ahora están disponibles públicamente, ofreciendo a los equipos de todo el mundo la oportunidad de construir sobre los hombros de lo que se compartió en ETHDenver.

Eventos paralelos y reuniones comunitarias que enriquecen la experiencia de ETHDenver​

Lo que realmente distingue a ETHDenver es su atmósfera de festival: decenas de eventos paralelos, tanto oficiales como no oficiales, crearon un rico tapiz de experiencias en torno a la conferencia principal. En 2025, más allá del National Western Complex donde se desarrollaba el contenido oficial, toda la ciudad bullía de encuentros, fiestas, hackatones y reuniones comunitarias. Estos eventos paralelos, a menudo organizados por patrocinadores o grupos locales de Web3, contribuyeron significativamente a la experiencia más amplia de ETHDenver.

En el frente oficial, el propio programa de ETHDenver incluía mini-eventos temáticos: el recinto tenía zonas como una Galería de Arte NFT, una Sala de Juegos Blockchain, un DJ Chill Dome e incluso una Zona Zen para relajarse. Los organizadores también organizaron eventos nocturnos como fiestas de apertura y clausura; por ejemplo, la fiesta de apertura no oficial “Crack’d House” el 26 de febrero por Story Protocol, que mezcló una actuación artística con anuncios de premios del hackatón. Pero fueron los eventos paralelos liderados por la comunidad los que realmente proliferaron: según una guía de eventos, se rastrearon más de 100 acontecimientos paralelos en el calendario Luma de ETHDenver.

Algunos ejemplos ilustran la diversidad de estas reuniones:

• Cumbres Técnicas y Hacker Houses: ElizaOS y EigenLayer organizaron una residencia de 9 días, la Vault AI Agent Hacker House, para entusiastas de IA+Web3. El equipo de StarkNet organizó una hacker house de varios días que culminó en una noche de demostraciones para proyectos en su ZK-rollup. Estos proporcionaron entornos enfocados para que los desarrolladores colaboraran en pilas tecnológicas específicas fuera del hackatón principal.
• Eventos de Networking y Fiestas: Cada noche ofrecía una variedad de opciones. Builder Nights Denver el 27 de febrero, patrocinado por MetaMask, Linea, EigenLayer, Wormhole y otros, reunió a innovadores para charlas informales con comida y bebida. 3VO’s Mischief Minded Club Takeover, respaldado por Belong, fue una fiesta de networking de alto nivel para líderes en la tokenización comunitaria. Para los que buscaban pura diversión, el BEMO Rave (con Berachain y otros) y rAIve the Night (una rave con temática de IA) mantuvieron a la multitud cripto bailando hasta altas horas de la noche, mezclando música, arte y cultura cripto.
• Reuniones de Intereses Especiales: Las comunidades de nicho también encontraron su espacio. Meme Combat fue un evento exclusivamente para entusiastas de los memes para celebrar su papel en el mundo cripto. House of Ink se dirigió a artistas y coleccionistas de NFT, convirtiendo un espacio de arte inmersivo (Meow Wolf Denver) en una vitrina para el arte digital. La Cumbre SheFi el 26 de febrero reunió a mujeres en Web3 para charlas y networking, con el apoyo de grupos como World of Women y Celo, destacando un compromiso con la diversidad y la inclusión.
• Encuentros de Inversores y Creadores de Contenido: Ya mencionamos los eventos de VC; además, un Encuentro de KOL (Líderes de Opinión Clave) el 28 de febrero permitió a influencers y creadores de contenido cripto discutir estrategias de participación, mostrando la intersección de las redes sociales y las comunidades cripto.

Crucialmente, estos eventos paralelos no fueron solo entretenimiento; a menudo sirvieron como incubadoras de ideas y relaciones por derecho propio. Por ejemplo, la Cumbre de Capital Tokenizado 2025 profundizó en el futuro de los mercados de capitales on-chain, probablemente generando colaboraciones entre emprendedores fintech y desarrolladores de blockchain presentes. La Hacker House de Gaming On-Chain proporcionó un espacio para que los desarrolladores de juegos compartieran mejores prácticas, lo que podría llevar a una polinización cruzada entre proyectos de gaming en blockchain.

Para los profesionales que asisten a grandes conferencias, el modelo de ETHDenver subraya que el valor se encuentra tanto fuera como dentro del escenario principal. La amplitud de la programación no oficial permitió a los asistentes personalizar su experiencia: ya sea que el objetivo fuera conocer inversores, aprender una nueva habilidad, encontrar un cofundador o simplemente relajarse y crear camaradería, había un evento para ello. Muchos veteranos aconsejan a los recién llegados: “No solo asistas a las charlas, ve a los encuentros y saluda”. En un espacio tan impulsado por la comunidad como Web3, estas conexiones humanas a menudo se traducen en colaboraciones de DAO, acuerdos de inversión o, como mínimo, amistades duraderas que abarcan continentes. La vibrante escena paralela de ETHDenver 2025 amplificó la conferencia principal, convirtiendo una semana en Denver en un festival multidimensional de innovación.

Conclusiones clave y perspectivas accionables​

ETHDenver 2025 demostró una industria Web3 en pleno florecimiento de innovación y colaboración. Para los profesionales del sector, surgen varias conclusiones claras y acciones a seguir de este análisis profundo:

• Diversificación de Tendencias: El evento dejó en evidencia que Web3 ya no es monolítico. Dominios emergentes como la integración de IA, DePIN y la tokenización de RWA son tan prominentes como DeFi y los NFTs. Perspectiva accionable: Mantente informado y adaptable. Los líderes deberían asignar recursos de I+D o inversión a estas verticales en ascenso (p. ej., explorar cómo la IA podría mejorar su dApp, o cómo los activos del mundo real podrían integrarse en plataformas DeFi) para aprovechar la próxima ola de crecimiento.
• El Futuro es Cross-Chain: Con la participación activa de importantes protocolos no pertenecientes a Ethereum, los muros entre ecosistemas se están derrumbando. La interoperabilidad y las experiencias de usuario multicadena atrajeron una enorme atención, desde MetaMask añadiendo soporte para Bitcoin/Solana hasta cadenas basadas en Polkadot y Cosmos cortejando a los desarrolladores de Ethereum. Perspectiva accionable: Diseñar para un mundo multicadena. Los proyectos deberían considerar integraciones o puentes que aprovechen la liquidez y los usuarios de otras cadenas, y los profesionales podrían buscar alianzas entre comunidades en lugar de permanecer en silos.
• La Comunidad y los Bienes Públicos Importan: El lema del “Año de los Regenerados” no fue solo retórica; impregnó el contenido a través de discusiones sobre la financiación de bienes públicos, la votación cuadrática para los hacks y eventos como la Cumbre SheFi. El desarrollo ético y sostenible y la propiedad comunitaria son valores clave en el ethos de Ethereum. Perspectiva accionable: Incorporar principios regenerativos. Ya sea apoyando iniciativas de código abierto, utilizando mecanismos de lanzamiento justos o alineando los modelos de negocio con el crecimiento de la comunidad, las empresas de Web3 pueden ganar buena voluntad y longevidad al no ser puramente extractivas.
• Sentimiento de los Inversores: Cautelosos pero Audaces: A pesar de los rumores de mercado bajista, ETHDenver demostró que los VCs están buscando activamente y dispuestos a apostar fuerte por los próximos capítulos de Web3. Sin embargo, también están reconsiderando cómo invertir (p. ej., de manera más estratégica, quizás con más supervisión sobre el ajuste producto-mercado y una apertura a la financiación comunitaria). Perspectiva accionable: Si eres una startup, enfócate en los fundamentos y la narrativa. Los proyectos que destacaron tenían casos de uso claros y, a menudo, prototipos funcionales (¡algunos construidos en un fin de semana!). Si eres un inversor, la conferencia afirmó que la infraestructura (L2s, seguridad, herramientas de desarrollo) sigue siendo de alta prioridad, pero diferenciarse a través de tesis en IA, gaming o redes sociales puede posicionar a un fondo a la vanguardia.
• La Experiencia del Desarrollador está Mejorando: ETHDenver destacó muchos nuevos kits de herramientas, SDKs y frameworks que reducen la barrera para el desarrollo de Web3, desde herramientas de abstracción de cuentas hasta bibliotecas de IA on-chain. Perspectiva accionable: Aprovechar estos recursos. Los equipos deberían experimentar con las últimas herramientas de desarrollo presentadas (p. ej., probar ese Smart SSO de zkSync para inicios de sesión más fáciles, o usar los recursos de la Open Agents Alliance para un proyecto de IA) para acelerar su desarrollo y mantenerse por delante de la competencia. Además, las empresas deberían continuar participando en hackatones y foros de desarrolladores abiertos como una forma de encontrar talento e ideas; el éxito de ETHDenver en convertir a hackers en fundadores es prueba de ese modelo.
• El Poder de los Eventos Paralelos: Por último, la explosión de eventos paralelos enseñó una lección importante sobre el networking: las oportunidades a menudo aparecen en entornos informales. Un encuentro casual en un happy hour o un interés compartido en un pequeño encuentro puede crear conexiones que definan una carrera. Perspectiva accionable: Para quienes asisten a conferencias de la industria, planificar más allá de la agenda oficial. Identifica eventos paralelos alineados con tus objetivos (ya sea conocer inversores, aprender una habilidad de nicho o reclutar talento) y sé proactivo en la participación. Como se vio en Denver, aquellos que se sumergieron por completo en el ecosistema de la semana se fueron no solo con conocimiento, sino con nuevos socios, contrataciones y amigos.

En conclusión, ETHDenver 2025 fue un microcosmos del impulso de la industria Web3: una mezcla de discurso tecnológico de vanguardia, energía comunitaria apasionada, movimientos de inversión estratégicos y una cultura que combina la innovación seria con la diversión. Los profesionales deberían ver las tendencias y perspectivas del evento como una hoja de ruta hacia dónde se dirige Web3. El siguiente paso accionable es tomar estos aprendizajes, ya sea un nuevo enfoque en la IA, una conexión hecha con un equipo de L2 o la inspiración de un proyecto de hackatón, y traducirlos en estrategia. En el espíritu del lema favorito de ETHDenver, es hora de #BUIDL sobre estas ideas y ayudar a dar forma al futuro descentralizado que tantos en Denver se reunieron para imaginar.

Nos complace compartir una oportunidad transformadora en Altera.al, una startup de IA revolucionaria que recientemente ha causado sensación con su trabajo pionero en el desarrollo de humanos digitales. Destacada en MIT Technology Review, Altera.al ha demostrado un progreso notable al crear agentes de IA que pueden desarrollar comportamientos similares a los humanos, formar comunidades e interactuar de manera significativa en espacios digitales.

Sobre Altera.al​

Fundada por Robert Yang, quien dejó su puesto como profesor asistente de neurociencia computacional en MIT para perseguir esta visión, Altera.al ya ha asegurado más de 11 millones de dólares en financiación de inversores de renombre, incluidos A16Z y la firma de capital de riesgo emergente de Eric Schmidt. Su reciente demostración del Proyecto Sid mostró agentes de IA que desarrollan espontáneamente roles especializados, forman conexiones sociales e incluso crean sistemas culturales dentro de Minecraft, un paso significativo hacia su objetivo de crear agentes de IA verdaderamente autónomos que puedan colaborar a gran escala.

Por qué ahora es un momento emocionante para unirse​

Altera.al ha logrado un importante avance técnico en su misión de desarrollar máquinas con cualidades humanas fundamentales. Su trabajo va más allá del desarrollo tradicional de IA: están creando seres digitales que pueden:

• Formar comunidades y jerarquías sociales
• Desarrollar roles y responsabilidades especializadas
• Crear y difundir patrones culturales
• Interactuar de manera significativa con humanos en espacios digitales

A quién buscan​

Tras su reciente avance, Altera.al está ampliando su equipo y ofreciendo paquetes de compensación excepcionales que van de $600,000 a$1,000,000 para:

• Expertos en investigación de agentes de IA
• Contribuyentes individuales fuertes en:
  • Sistemas distribuidos
  • Seguridad
  • Sistemas operativos

Cómo aplicar​

¿Listo para ser parte de este viaje revolucionario? Aplica directamente a través de su página de carreras: https://jobs.ashbyhq.com/altera.al

Únete al futuro del desarrollo de humanos digitales​

Esta es una oportunidad única para trabajar en la intersección de la inteligencia artificial y la modelación del comportamiento humano, con un equipo que ya está demostrando resultados notables. Si te apasiona empujar los límites de lo posible en IA y la interacción humano‑máquina, Altera.al podría ser tu próxima aventura.

---

Para más actualizaciones sobre oportunidades revolucionarias en tecnología y blockchain, síguenos en Twitter o únete a nuestra comunidad en Discord.

Este artículo forma parte de nuestro compromiso continuo de apoyar la innovación y conectar talento con oportunidades transformadoras en la industria tecnológica.