Proof of AI: una nube de código abierto que paga a los desarrolladores sobre los que se ejecuta

Hay dos problemas duros debajo de cada discurso de «IA descentralizada», y la mayoría de los proyectos les hace un gesto a los dos.

El primero: ¿cómo confiáis en un resultado que no habéis calculado? Si una máquina remota dice «el modelo produjo X», ¿cómo sabéis que ejecutó el modelo, y no uno más barato, ni basura, ni una mentira en caché?

El segundo es más callado y, creemos, más importante: toda la pila de IA está construida sobre código abierto que casi nadie paga. Vuestro servidor de inferencia, vuestro tokenizador, vuestro índice vectorial, vuestra biblioteca criptográfica: escritos por gente que no ve nada de los ingresos que genera su código.

Proof of AI (PoAI) es nuestra respuesta al primero. Nuestro compromiso de reparto es la respuesta al segundo. Este artículo es un relato honesto de lo que está en marcha hoy, de lo que está cableado pero dormido y de lo que sigue en la hoja de ruta. Vamos a ser explícitos sobre qué es cada cosa, porque el sentido de todo esto es la verificabilidad.

Qué demuestra de verdad Proof of AI

El cómputo de IA es famoso por lo difícil que es verificarlo, porque la aritmética de coma flotante no es determinista: el mismo modelo, la misma entrada y la misma GPU pueden producir números ligeramente distintos según el orden de las operaciones y la planificación. No se puede consensuar un número que cambia cada vez que se calcula.

PoAI quita el no determinismo en lugar de intentar demostrar alrededor de él:

1. Inferencia solo con enteros. Los pesos y las activaciones se cuantizan a int8. La acumulación es int32, el escalado es un desplazamiento aritmético a la derecha, las salidas saturan y las funciones trascendentes son tablas de consulta congeladas: nunca exp() ni rsqrt(). El resultado es un paso hacia delante idéntico bit a bit en CPU, Metal, CUDA y AMD.

2. Recómputo, no confianza. El transformer de enteros se expone como un precompilado de la EVM. El modelo de confianza es el más simple que existe: cada validador vuelve a ejecutar el cómputo idéntico durante la ejecución del bloque. Si vuestra salida no coincide con lo que produce la máquina de los demás, vuestro bloque se rechaza. Sin comité, sin hardware especial, sin prueba que falsificar.

Esta es la variante de PoAI que nuestra investigación describió primero en Proof of AI: el cómputo verificable como primitiva de consenso (ZIP-002), ahora entregada como código.

Esta parte está en marcha

La clave es una multiplicación de matrices int8 determinista — gemm_i8 — implementada de forma idéntica al byte en Go, Rust y C++, con núcleos de GPU (Metal, CUDA, HIP) que pasan las mismas pruebas de respuesta conocida. La implementación en Go es un precompilado de EVM registrado en la dirección 0x0300...0003, importado en blanco por las EVM de Lux, Zoo y Hanzo, de modo que el mismo camino de inferencia determinista se comparte entre las tres cadenas. Una secuencia de tokens de oro se afirma en cada lenguaje como prueba:

prompt  1 7 13 2  →  4 28 21 17 2 19 43 35 36 15

Si ese vector difiere alguna vez entre dos máquinas, la CI se pone roja. Eso es lo que «verificable» significa en la práctica.

Esta parte es hoja de ruta, con honestidad

• Tamaño del modelo. El precompilado en cadena ejecuta hoy un transformer de referencia pequeño. El porte de un modelo de producción (Qwen3-0.6B / zen-nano) está especificado y en curso: recomputar un modelo de frontera en cada validador no es el objetivo; sí lo son los modelos verificables pequeños y la verificación muestreada de los grandes.
• Pruebas criptográficas. Las pruebas zkML y la ejecución confidencial (TEE) están diseñadas y esbozadas para una entrega posterior. La garantía de hoy es determinismo que podéis volver a ejecutar, que es una garantía real, solo que no una prueba sucinta.
• Atestación de hardware. Para los modelos demasiado grandes para recomputar en cadena, el ancla de confianza es una atestación de hardware. La atestación AMD SEV-SNP está implementada de extremo a extremo en nuestra pila (verificación completa de la cadena de certificados contra el servicio de claves de AMD); Intel TDX y el cómputo confidencial de GPU de NVIDIA están andamiados, no terminados.

Preferimos deciros esto a publicar una diapositiva que diga «IA verificada con zk».

El reparto de código abierto: el 25%, por diseño

Este es el compromiso, y está en nuestro código, no solo en un artículo: el 75% de los ingresos atribuibles de la nube se queda en la plataforma; el 25% se acumula para los desarrolladores de código abierto cuyos paquetes la nube ejecutó de verdad.

Cómo funciona la atribución, de extremo a extremo:

Paso	Qué ocurre
Compilación	Cada imagen que produce nuestro sistema de compilación recibe una lista de materiales de software (syft → CycloneDX): el grafo exacto de dependencias de lo que se entregó.
Atribución	Un motor de git blame asigna cada dependencia a sus autores, línea a línea, y produce porcentajes de contribución por autor.
Medición	La nube ya mide el uso por organización para facturar. Ese uso es la base del coste.
Reparto	El uso se reparte por el grafo de dependencias, ponderado por la contribución, y el 25% del importe atribuible se reserva para quienes contribuyen.
Pago	Se paga a quienes contribuyen: para empezar, en créditos Hanzo que no caducan; los raíles de cripto y de dinero fiduciario vienen después.

Estamos siendo precisos con el estado: el generador de SBOM, el motor de atribución, el reparto del 25%, la medición y el modelo de pago existen todos en el código hoy. Lo que estamos cableando ahora es el tejido conjuntivo: activar la ingesta de SBOM, programar la ejecución del pago y encaminar dinero real por el raíl que ya paga a destinatarios arbitrarios. Los primeros pagos van a las dependencias sobre las que se ejecuta el propio Hanzo Cloud, como implementación de referencia.

Enlazad vuestro repositorio y cobrad

El estado final es de autoservicio: conectad un repositorio de GitHub, verificad que es vuestro, elegid cómo queréis que se os pague y recibid una parte siempre que Hanzo Cloud ejecute software que dependa del vuestro. Ese flujo de alta es la pieza que estamos construyendo ahora. Cuando llegue, será el sujeto literal del título de este artículo, y podréis verificar vuestros propios ingresos contra el SBOM que los produjo.

Ejecutar un nodo y compartir la nube

Operadores de nodos. Hanzo Node permite que una máquina se inscriba con una identidad criptográfica, anuncie lo que sabe hacer, reciba trabajo por una red entre pares y cobre por ello mediante liquidación en moneda estable (x402). Ese bucle es real hoy para trabajo de agentes y de herramientas. El mercado de cómputo plenamente medido en hardware y atestiguado — donde vendéis tiempo de GPU bajo una atestación TEE y liquidáis en cadena — es la dirección, construida sobre las primitivas de atestación y de liquidación de arriba, no un atajo alrededor de ellas.

Referidos y difusión. Referid a un desarrollador o a una organización y los dos ganáis créditos; los afiliados ganan una parte por tramos del gasto referido. Esto está en marcha en el sistema de facturación hoy, con control de fraude y con pruebas: la misma maquinaria de reparto de ingresos sobre la que se construye el pago al código abierto.

Por qué importa

Una nube de IA que no puede demostrar sus resultados está pidiendo confianza ciega. Una nube de IA que se lucra del código abierto sin devolverle nada no es sostenible. Proof of AI aborda lo primero con el mecanismo más aburrido y más robusto que hay — el recómputo determinista — y nuestro reparto del 25% aborda lo segundo con un número que escribimos en el código.

El marcador honesto: el núcleo de inferencia verificable está entregado y probado; el conducto de pagos está construido y se está encendiendo; las pruebas, el porte del modelo grande y la puerta de autoservicio son hoja de ruta con cimientos reales debajo.

Seguiremos publicando lo que es real y etiquetando lo que no lo es. Es la única forma de que «Proof of AI» signifique algo.

---

Hanzo AI es Techstars '17. La auditoría técnica detrás de este artículo — cada afirmación asignada a un fichero y una línea — se mantiene internamente y dirige el plan de construcción.