ZK Color Sort verifica en cadena las puntuaciones diarias de los puzzles con pruebas de conocimiento cero

2026-08-19

gaming · zero-knowledge · smart-contracts · mainnet · puzzle · discovery · web · updated

ZK Color Sort verifica en cadena las puntuaciones diarias de los puzzles con pruebas de conocimiento cero

Un puzzle diario con una tabla de clasificación criptográfica

ZK Color Sort parece el clásico pasatiempo de verter colores que se juega en el móvil mientras esperas al café: doce tubos, diez colores, vierte hasta que cada tubo contenga un solo color. La gracia está en lo que pide la página cuando terminas. «Conecta tu billetera de Algorand para desbloquear esta función», se lee junto a un botón de «Puntuaciones» y un contador de movimientos. No es un muro de pago. Conectar una billetera compatible — actualmente Lute o Pera — es la puerta de entrada al verdadero propósito del juego: enviar tu puntuación a un contrato inteligente en la mainnet de Algorand junto con una prueba de conocimiento cero, un certificado criptográfico que demuestra que una afirmación es cierta sin revelar los datos que hay detrás. Aquí la afirmación es «He resuelto este puzzle concreto en N movimientos», y los datos que se mantienen privados son la propia secuencia de movimientos. Jugar al puzzle no requiere billetera en absoluto; el marcador protegido por prueba es la capa en cadena.

El puzzle del día se extrae de la propia cadena. El frontend pide a un indexador de Algorand la primera cabecera de bloque después de la medianoche UTC y deriva de forma determinista el tablero a partir de la semilla de esa cabecera, de modo que el reto es público y reproducible a partir del historial de la cadena, en lugar de ser elegido por un desarrollador. Las reglas siguen el formato estándar de Color Sort, fijado con precisión en el README del proyecto: doce tubos de capacidad cuatro; diez colores que aparecen exactamente cuatro veces cada uno; dos tubos vacíos para verter; un movimiento legal mueve la racha contigua máxima de un solo color a un tubo vacío o a uno cuyo color superior coincida; el puzzle está resuelto cuando cada tubo no vacío es completamente monocromo. La puntuación es el número de movimientos; cuanto menor, mejor, y las mejores puntuaciones locales con sus historiales completos de movimientos viven en el localStorage del navegador. El registro en cadena nunca acepta una puntuación que no supere el mejor registro propio del jugador.

Qué demuestra realmente la prueba de conocimiento cero

Cualquier tabla de clasificación en cadena para un juego de habilidad tiene un problema de credibilidad: un contrato que acepta un número aceptará cualquier número. Un servidor de confianza que valide las partidas reintroduce la centralización, y publicar la solución ganadora revela la estrategia que la produjo. ZK Color Sort intenta una tercera vía: probarlo, no mostrarlo.

Cuando un jugador envía su resultado, el navegador ejecuta un circuito de Circom a través de snarkjs, la biblioteca de generación de pruebas en JavaScript de código abierto, y produce una prueba Groth16, uno de los esquemas de conocimiento cero más utilizados. La primera vez, la descarga incluye la clave de prueba de aproximadamente 55 MB que el juego distribuye como recurso estático; a partir de ahí, todo el proceso se ejecuta en el cliente, sin ningún servidor de pruebas detrás del juego. La elección de la pila tecnológica es deliberada: el README de la biblioteca snarkjs-algorand señala que gnark, el compilador del verificador alternativo AlgoPlonk, no admite WebAssembly, lo que descartaría la generación de pruebas en el navegador; snarkjs está escrito en TypeScript y se ejecuta donde está el jugador.

El circuito está ajustado al perfil exacto de este juego — doce tubos, capacidad cuatro, hasta 120 movimientos, diez colores, dos tubos vacíos — y aplica toda la semántica del juego: un tablero inicial válido, movimientos legales según las reglas de vertido anteriores, transiciones de estado correctas tras cada movimiento, un tablero final completamente resuelto, y un número de movimientos declarado igual al número de movimientos realizados. Lo que es público y lo que permanece privado es todo el diseño:

Concepto	Implicación en el mundo real
Público: el tablero inicial	Cualquiera puede confirmar a qué puzzle corresponde una puntuación
Público: el número de movimientos	El número que almacena el registro y el que ordena la tabla de clasificación
Público: la identidad del puzzle y la dirección de la billetera	Vinculados a la prueba, de modo que una prueba generada para un puzzle o una cuenta no puede reutilizarse para otra
Privado: la secuencia completa de movimientos	Los observadores pueden verificar la afirmación sin copiar la estrategia ganadora — la muerte habitual de las tablas de clasificación en cadena para puzzles

El registro de puntuaciones en cadena

El extremo receptor es un contrato inteligente llamado PuzzleScores, escrito en Algorand TypeScript, el lenguaje de contratos moderno compilado con Puya que ha sustituido al antiguo PyTeal. Almacena una puntuación por par (puzzle, billetera) en el almacenamiento de cajas — un estado de clave-valor adjunto al propio contrato. La clave es un código de puzzle de 20 bytes concatenado con la dirección de la billetera de 32 bytes (52 bytes en total); el valor es un único byte, lo que limita las puntuaciones almacenadas a 255 movimientos, muy por encima de lo que cualquier resolución de este puzzle necesita. Crear una entrada cuesta exactamente el requisito de saldo mínimo de la caja, que el contrato calcula en tiempo de ejecución (2,500 microALGO base más 400 por byte) y reembolsa si el jugador elimina la entrada mediante removeScore. Los métodos de solo lectura permiten al jugador consultar su propia puntuación o la de cualquier otro.

Existen dos vías de escritura: addScore para una primera entrada y updateScore, que el contrato solo acepta cuando la nueva puntuación es estrictamente inferior a la almacenada. Ambas requieren una transacción «verificadora» acompañante en el mismo grupo atómico, y aquí es donde realmente se comprueba la prueba. El frontend compone un grupo de tres transacciones: un pago de valor cero firmado por una cuenta de firma lógica (una cuenta cuya autoridad es un programa en lugar de una clave privada, derivada de la clave de verificación del juego), el pago del saldo mínimo y la llamada a la aplicación. El contrato verifica que el pago de atestación proviene de la dirección verificadora configurada y que las señales públicas de la prueba coinciden con la puntuación declarada, el código del puzzle y el remitente; la matemática de verificación Groth16 se ejecuta dentro del programa de firma lógica, que produce el pago de atestación solo cuando acepta el testigo. Dado que la puntuación, el puzzle y la billetera del jugador están todos vinculados a la misma prueba, una presentación generada para un puzzle o una cuenta no puede reutilizarse para otra. En el frontend, el mismo almacén de cajas alimenta una vista de percentiles: después de conectarse, el juego escanea las entradas en cadena del puzzle del día e indica al jugador a cuántos otros ha superado.

En vivo en mainnet: ¿pero quién juega?

El contrato es real, está desplegado y al día: la aplicación 3603459425 se creó en la ronda 62,209,315 el 16 de junio de 2026 por la cuenta que está detrás del proyecto (que posee el nombre .algo tools.orange.algo), y su verificador se configuró minutos después. Ahora contiene 94 cajas de puntuación, y el libro mayor muestra llamadas a la aplicación tan recientes como la ronda 64,130,520 — el 16 de agosto de 2026, dos días antes de redactar este artículo. El paquete web confirma que la red predeterminada del frontend es mainnet, coincidiendo con el ID de aplicación en la configuración de red del repositorio.

Sin embargo, el libro mayor de remitentes cuenta una historia de adopción más modesta. La billetera del propio desarrollador domina tanto el registro de transacciones como las claves de las cajas; una segunda billetera que envía se creó el día del lanzamiento y fue financiada con 1 ALGO por el desarrollador — una cuenta de prueba. Otras dos billeteras rastrean su primera financiación hasta cuentas no relacionadas creadas en 2022 y 2024, lo que es coherente con jugadores externos, aunque ninguna lleva un nombre .algo. La lectura honesta: es un registro activo pero pequeño, con la mayoría de las entradas atribuibles a las pruebas del propio desarrollador y sin evidencia de una base de jugadores sustancial todavía.

El proyecto en sí es obra de un único desarrollador — la cuenta de GitHub funk-af, cuyo perfil nombra al propietario como «Andrew» — y la misma cuenta publica otros trabajos de contratos de Algorand, incluidos repositorios descritos como contratos inteligentes para Baanx y para el protocolo de financiación Immersve flexi-card. El repositorio del juego muestra 18 commits de junio de 2026 y ninguna actividad desde el 18 de junio, mientras que el frontend desplegado y el contrato en cadena siguen funcionando.

Dónde tiene límites el modelo de confianza

Tres advertencias importan para cualquiera que lea este registro como algo más que un juego. Primero, la derivación del puzzle diario es una convención del frontend, no una regla del contrato: el contrato nunca comprueba que un código de puzzle enviado corresponda al puzzle actual derivado del bloque, y el circuito solo valida que un puzzle esté bien formado y resuelto. Se aceptaría una prueba para cualquier puzzle bien formado del mismo perfil de circuito; nada en cadena ancla una presentación a la fecha actual. Segundo, tanto la dirección verificadora como el propio contrato están controlados por el creador — setVerifier y updateApplication están restringidos a la billetera del creador —, por lo que la integridad del registro depende en última instancia de que un único desarrollador no cambie el verificador ni reescriba el contrato. Tercero, la pila de pruebas no está auditada: el README de snarkjs-algorand advierte que el SDK «es un trabajo en curso y aún no es estable» y que «El código de este repositorio no ha sido auditado. ¡Úsalo bajo tu propio riesgo!»

Nada de eso resta valor a lo que aquí es genuinamente notable: una demostración integral y funcional de generación de pruebas Groth16 en el navegador que alimenta un verificador en cadena en Algorand mainnet, con un puzzle diario generado a partir de las cabeceras de bloque de la propia cadena. Si el patrón madura — un verificador auditado, anclaje del puzzle garantizado por el contrato y jugadores reales — los juegos de habilidad verificados con ZK son un nicho con una base creíble. Por ahora, es un experimento honesto y pequeño, y funciona.

Fuentes

Source: https://zk-colorsort.netlify.app/