#opg $OPG Hermanos, en la última vez desmontamos la separación de la ejecución y la verificación en HACA. Hoy cambiemos de ángulo y desmenucemos cómo realmente funciona el nodo de verificación; esto es la clave para que OGP pueda arrancar
La lógica de consenso en las cadenas tradicionales es muy simple: cada nodo de verificación vuelve a ejecutar la misma transacción, y compara el resultado. Pero la inferencia con IA no funciona así. Si 100 nodos ejecutan un LLM de 70B cada uno, obtienes el mismo resultado a un costo 100 veces mayor: literalmente es como desnudarse para mear.
¿Cómo lo hace Opg? Los nodos de verificación ni tocan el modelo.
Toda la red solo hace tres cosas: registro del nodo, procesamiento de pagos y liquidación de pruebas. Los nodos de inferencia terminan de correr el modelo, generan una prueba criptográfica de hardware TEE o una prueba de conocimiento cero ZKML, y se la entregan a toda la red. Los nodos de toda la red verifican solo la validez criptográfica: comprueban si las firmas están bien, si los valores PCR tienen sentido. No necesitan saber qué prompt es, qué modelo se usó ni qué devolvió. Verificar una prueba es cosa de milisegundos; no tiene nada que ver con la latencia de segundos de volver a inferir.
Lo más suculento es que—la inferencia y la verificación ocurren en líneas de tiempo distintas. La solicitud del usuario se envía directamente a los nodos de inferencia y recibe respuesta al instante, sin pasar en todo momento por la cadena. La verificación es asíncrona: el resto valida poco a poco y se registra en la cadena con calma. Así se desacoplan “rápido” y “confiable”.
La capa de consenso usa CometBFT, compatible con Cosmos SDK y EVM. Se elige este stack por ser maduro: los desarrolladores pueden empezar directamente con Hardhat, Foundry y MetaMask. Pero ojo: el whitepaper dice claramente que la funcionalidad nativa del contrato inteligente para llamar a inferencia de IA aún no está en vivo. Por ahora, está principalmente orientado a llamadas desde la capa de aplicación; para llamadas desde la capa de contratos, toca esperar.
Una frase sobre los tokens: el total es 1.000 millones, y en la práctica el TGE circulante es solo ~10%. Asignación: 40% ecosistema, 15% fundación, 15% contribuyentes, 10% inversores, 10% recompensas por staking, 6% liquidez, 4% airdrop. Las recompensas por staking se bloquean 96 meses; la inflación las comprime bastante. Como el float es pequeño, la volatilidad es grande: tenlo claro. Digo en serio: el diseño de esta capa de verificación de OGP es más honesto que la mayoría de proyectos de “blockchain + IA”. Porque lo que hace es verificar resultados de IA en cadena, no “ejecutar IA en cadena”; y esas dos cosas tienen diferencias esenciales. Pero el reto también está ahí: actualmente hay 500.000+ pruebas de verificación y 2.000.000+ de inferencia; la brecha de escala todavía es enorme. En el próximo semestre, vigilen los datos reales de llamadas a la capa de verificación; es más útil que mirar cualquier gráfico de K
Hermanos, ¿esta ruta de una capa de verificación de IA descentralizada se puede hacer bien? Dejen sus comentarios, @OpenGradient
La lógica de consenso en las cadenas tradicionales es muy simple: cada nodo de verificación vuelve a ejecutar la misma transacción, y compara el resultado. Pero la inferencia con IA no funciona así. Si 100 nodos ejecutan un LLM de 70B cada uno, obtienes el mismo resultado a un costo 100 veces mayor: literalmente es como desnudarse para mear.
¿Cómo lo hace Opg? Los nodos de verificación ni tocan el modelo.
Toda la red solo hace tres cosas: registro del nodo, procesamiento de pagos y liquidación de pruebas. Los nodos de inferencia terminan de correr el modelo, generan una prueba criptográfica de hardware TEE o una prueba de conocimiento cero ZKML, y se la entregan a toda la red. Los nodos de toda la red verifican solo la validez criptográfica: comprueban si las firmas están bien, si los valores PCR tienen sentido. No necesitan saber qué prompt es, qué modelo se usó ni qué devolvió. Verificar una prueba es cosa de milisegundos; no tiene nada que ver con la latencia de segundos de volver a inferir.
Lo más suculento es que—la inferencia y la verificación ocurren en líneas de tiempo distintas. La solicitud del usuario se envía directamente a los nodos de inferencia y recibe respuesta al instante, sin pasar en todo momento por la cadena. La verificación es asíncrona: el resto valida poco a poco y se registra en la cadena con calma. Así se desacoplan “rápido” y “confiable”.
La capa de consenso usa CometBFT, compatible con Cosmos SDK y EVM. Se elige este stack por ser maduro: los desarrolladores pueden empezar directamente con Hardhat, Foundry y MetaMask. Pero ojo: el whitepaper dice claramente que la funcionalidad nativa del contrato inteligente para llamar a inferencia de IA aún no está en vivo. Por ahora, está principalmente orientado a llamadas desde la capa de aplicación; para llamadas desde la capa de contratos, toca esperar.
Una frase sobre los tokens: el total es 1.000 millones, y en la práctica el TGE circulante es solo ~10%. Asignación: 40% ecosistema, 15% fundación, 15% contribuyentes, 10% inversores, 10% recompensas por staking, 6% liquidez, 4% airdrop. Las recompensas por staking se bloquean 96 meses; la inflación las comprime bastante. Como el float es pequeño, la volatilidad es grande: tenlo claro. Digo en serio: el diseño de esta capa de verificación de OGP es más honesto que la mayoría de proyectos de “blockchain + IA”. Porque lo que hace es verificar resultados de IA en cadena, no “ejecutar IA en cadena”; y esas dos cosas tienen diferencias esenciales. Pero el reto también está ahí: actualmente hay 500.000+ pruebas de verificación y 2.000.000+ de inferencia; la brecha de escala todavía es enorme. En el próximo semestre, vigilen los datos reales de llamadas a la capa de verificación; es más útil que mirar cualquier gráfico de K
Hermanos, ¿esta ruta de una capa de verificación de IA descentralizada se puede hacer bien? Dejen sus comentarios, @OpenGradient