Dónde se usa realmente el conocimiento cero: zkLogin, coprocesadores y controles de identidad

2026-08-24

Los sistemas de conocimiento cero se entienden mejor cuando cada prueba está vinculada a una afirmación concreta. Una prueba puede ocultar un campo de una credencial, certificar un cálculo off-chain o mostrar que se cumplió una regla de identidad sin publicar el documento original. No convierte automáticamente cada componente en trustless ni transforma un inicio de sesión en una identidad universal. Este texto fue revisado con la documentación indicada el 10 de agosto de 2026 y sigue el límite entre una prueba ZK, zkLogin, los coprocesadores ZK y los controles de identidad.

Qué oculta realmente una prueba zero-knowledge

Una prueba zero-knowledge permite que un prover convenza a un verifier de que una afirmación es cierta mientras mantiene privados determinados datos witness. La afirmación puede ser que un token firmado contiene una relación concreta, que un programa produjo un resultado o que una credencial cumple una regla. La prueba no es la afirmación. Es evidencia de una relación entre entradas públicas y privadas definida por un circuito o programa específico.

Esta diferencia importa porque la privacidad es selectiva. El verifier puede conocer un resultado booleano, un commitment público, un identificador de red, un identificador de programa o una marca de tiempo sin conocer la entrada privada. Una prueba de un umbral de edad puede ocultar la fecha de nacimiento, pero no demuestra por sí sola quién emitió la credencial, si el issuer es legítimo o si el verifier aplicó la política correcta.

Por eso, la pregunta práctica no es si un producto usa ZK. Hay que preguntar qué es público, qué es privado, quién genera el witness, qué claves o parámetros de setup requieren confianza y quién verifica el resultado. Un sound proof todavía puede depender de un proveedor OAuth, un servicio de salt, un indexer, una capa de disponibilidad de datos, un emisor de credenciales o una aplicación con una regla débil.

Cómo zkLogin vincula un inicio de sesión con una dirección

Quienes buscan zkLogin explained deberían empezar por el vínculo de identidad y no por la palabra wallet. zkLogin de Sui usa un inicio de sesión OpenID Connect que devuelve un JSON Web Token firmado. La aplicación también crea un par de claves efímeras de corta duración. El nonce del token se forma con la clave pública efímera, aleatoriedad y una epoch de caducidad, de modo que la sesión de transacción posterior queda vinculada al flujo de inicio de sesión.

La documentación de Sui separa el salt service y el proving service como funciones backend distintas. El salt se combina con el issuer, el audience de la aplicación y el subject claim para derivar una semilla de dirección. Mientras el salt sea privado, se puede desvincular el identificador OAuth de la dirección onchain. El proving service recibe el token y las entradas relevantes y genera una prueba Groth16 que comprueba las relaciones entre la firma del proveedor, el nonce, el claim y la derivación de la dirección.

La dirección y la clave de sesión tienen vidas distintas. La dirección puede permanecer estable mientras issuer, audience, subject y user salt sean los mismos, mientras que la clave efímera caduca en la epoch configurada. Un nuevo inicio de sesión genera una nueva clave de sesión y una nueva prueba para la misma dirección. Los validators verifican la prueba y la firma efímera antes de ejecutar la transacción. Es un flujo específico del protocolo, no una afirmación de que cualquier social login cree una identidad autocustodiada.

El límite de confianza se ve en los detalles. El proveedor OAuth autentica la cuenta y firma el token. La aplicación controla el frontend y la clave efímera. El servicio de salt puede ver entradas sensibles según su diseño y el proving service procesa el token y las entradas de la prueba. Sui señala que esos servicios pueden vincular identidad y salt en su propia visión, aunque el JWT no se publique onchain. El resultado de privacidad depende de estas suposiciones y de proteger salt y session key.

Qué calcula un ZK coprocessor

La expresión zk coprocessor explained se entiende mejor como una pregunta de arquitectura. Un coprocessor desplaza una tarea con muchos datos o cómputo fuera de la cadena de aplicación y devuelve un resultado junto con evidencia de que se usaron entradas autenticadas y el cálculo declarado. En un modelo pure ZK, un verifier contract puede comprobar la prueba y consumir el resultado sin repetir todo el cálculo.

Flujo de una prueba ZK desde una entrada privada hasta un resultado verificable

La documentación de Brevis muestra tres etapas: acceso a datos, cálculo de la aplicación y uso del resultado. La aplicación solicita datos históricos onchain, un prover off-chain ejecuta lógica personalizada y el resultado junto con la prueba se envía para verificación onchain. El patrón puede servir para un umbral de actividad, una regla de pertenencia, un cálculo de recompensa o una señal de riesgo. La prueba no certifica automáticamente que la fuente de datos era adecuada; certifica la relación que el sistema realmente demostró.

Esto es distinto de pedir simplemente una respuesta a un indexer. Una respuesta sin prueba exige confiar en quien seleccionó los datos y calculó el resultado. Un ZK coprocessor puede vincular el resultado con datos de cadena autenticados y un circuito, reduciendo esa confianza. Pero el circuito, los commitments, el sistema de pruebas, el verifier y el proceso de actualización pasan a ser componentes que deben revisarse.

Un coprocessor tampoco es una función fija de un producto. Brevis distingue un modo pure ZK y un modelo coChain u optimistic, con diferencias en latencia, coste y retos. RISC Zero describe la computación verificable de forma más general: el output de un programa incluye una receipt que un verifier puede revisar sin repetir la ejecución ni ver las entradas privadas. Cada despliegue aún necesita revisar su statement, la autenticación de entradas y su política de fallos.

Dónde termina la prueba de un control de identidad

Un control de identidad puede expresarse como una afirmación sobre una credencial, no como una prueba mágica sobre una persona. El verifier puede preguntar si un issuer firmó la credencial, si sigue vigente, si el subject supera un umbral de edad o si el identificador del documento aparece en una lista de revocación. Un circuito ZK puede ocultar los campos innecesarios y revelar solo el resultado mínimo que requiere la aplicación.

La frase zero knowledge identity verification debe separarse en los papeles de issuer, holder y verifier. W3C Verifiable Credentials describe una credencial como claims de un issuer que posee un subject o holder y que se presenta a un verifier con mecanismos para comprobar autenticidad e integridad. W3C DID describe identificadores y métodos de verificación, pero ningún estándar garantiza por sí solo que una persona, organización o documento real sea veraz.

Pensemos en una comprobación de edad. Una prueba puede mostrar que una fecha de nacimiento firmada es anterior al corte de una política sin revelar la fecha. No decide si el issuer verificó el documento de forma fiable, si la credencial pertenece al holder actual, si el corte es válido en una jurisdicción concreta o si la credencial fue revocada. Son preguntas distintas sobre issuer, binding, policy y lifecycle.

El mismo límite se aplica a sanciones, residencia, acreditación y unicidad de cuenta. Un circuito puede codificar el predicate issuer approved set and claim satisfies rule. No corrige un registro de emisores débil, una credencial robada, una wallet comprometida, un registro de origen incorrecto ni un feed de revocación incompleto. True significa que el predicate codificado se verificó con las entradas suministradas, no que todos los hechos reales detrás de ellas sean ciertos.

La privacidad es una decisión de diseño

ZK puede reducir la divulgación, pero la privacidad depende de todo el flujo. El verifier aún puede observar la dirección pública, el momento, la red, el audience de la aplicación, la frecuencia de las pruebas o el hecho de que se intentó una política. Las presentaciones repetidas pueden enlazarse si la aplicación reutiliza identificadores o commitments públicos. Los metadatos pueden revelar más que el witness oculto por el circuito.

zkLogin lo muestra mediante el salt y los claims de OpenID. El salt ayuda a desvincular el identificador OAuth de la dirección onchain, pero perderlo puede impedir recuperar la dirección y exponerlo puede hacer enlazable el subject claim. El proveedor OAuth, el frontend, el servicio de salt, el proving service y los validators ven partes distintas del flujo. Una revisión de privacidad debe describir esas visiones en lugar de tratar la prueba como un interruptor único.

En un coprocessor, la privacidad también depende de dónde se procesan los datos originales y el witness. El verifier onchain puede comprobar el resultado sin ver las entradas privadas, pero el prover off-chain o el proveedor de datos pudo verlas durante el cálculo. La aplicación puede publicar el resultado, el identificador de consulta, el rango de bloques o el commitment. Si también hay que ocultar las entradas al prover, un verifier ZK público puede no bastar y pueden requerirse private proving, ejecución segura o cálculo cifrado.

Es útil aplicar el principio de divulgación mínima: demostrar solo el predicate que necesita la aplicación, usar un audience específico o un domain separator, rotar el material de sesión según el protocolo y documentar los riesgos de retención y correlación. Estas medidas no eliminan la confianza, pero hacen revisables las rutas de confianza y divulgación que permanecen.

Qué debe nombrar el trust model

Empieza por el statement y los public inputs. Escribe exactamente qué acepta el verifier, qué datos están committed, cómo se autentican el chain state o la credencial y qué versión de software o circuito generó la prueba. Si un contract puede consumir el resultado, hay que nombrar el código del verifier, la autoridad de actualización, la ruta de emergencia y el tratamiento de datos obsoletos.

Después, nombra a los actores. En zkLogin están el proveedor OpenID, la aplicación, quien conserva la clave efímera, el salt service, el proving service y los validators de Sui. En el coprocessor se añaden la fuente de datos, el indexer o light client, el prover, el verifier y cualquier mecanismo de challenge o staking. En el control de identidad se añaden issuer, holder, wallet o presentation layer, verifier y servicio de revocación o estado. Un actor ausente en el esquema es una señal de riesgo.

Separa correctness de availability y recovery. Una prueba válida puede llegar tarde. Un proveedor puede rotar claves. El servicio de salt puede no estar disponible. Una credencial puede caducar. Una reorganización o regla de finality puede cambiar el conjunto de entradas. Una ruta optimistic del coprocessor puede depender de que alguien presente un challenge honesto dentro de una ventana. Son propiedades operativas que una prueba matemática no arregla automáticamente.

Por último, revisa las suposiciones de setup y actualización. Sui documenta una ceremony de Groth16 para el common reference string de zkLogin. Otros sistemas pueden usar pruebas transparentes, receipts de zkVM, trusted setup, comités, staking o una combinación. Pregunta quién puede cambiar el circuito, el verifier, el registro de emisores, la lista de proveedores, la fuente de datos o la política. Una prueba puede verificar correctamente la política de ayer y aun así responder mal a la política de hoy.

Cómo leer una afirmación de identidad ZK

Cuando la documentación dice que una función es privada, conviértelo en una tabla: privada frente a quién, visible para quién, durante cuánto tiempo y con qué método puede correlacionarse. Cuando dice trustless, pregunta qué actor se elimina y quién sigue siendo trusted para inputs, keys, availability, recovery y governance. Cuando dice verifiable, pregunta qué computation o credential relation concreta está cubierta.

Revisa la secuencia de este artículo en cinco pasos. Primero, examina statement y witness. Segundo, sigue el binding desde el token del proveedor o la credential hasta la application address o la presentation. Tercero, identifica cada off-chain computation y su authenticated data source. Cuarto, enumera las suposiciones de issuer, policy, revocation y holder detrás del ID check. Quinto, prueba la privacy leakage producida por metadatos, reutilización y visibilidad de servicios.

Así se mantienen separadas tres ideas. zkLogin puede vincular una transaction key de corta duración con claims de un flujo OpenID y ocultar determinados claim data a la chain. Un ZK coprocessor puede hacer verificable una off-chain computation respecto de datos declarados. Un ID check puede demostrar que se cumplió un credential predicate definido. Ninguna de estas afirmaciones demuestra por sí sola que el usuario sea honesto, que el issuer sea fiable, que los datos estén actualizados o que los servicios cercanos sean inocuos.

Ahí es donde realmente se usa zero knowledge: en una relación acotada entre input, computation y verification. El resultado no es una promesa de identidad invisible, sino un claim más pequeño y auditable con supuestos explícitos de privacidad y confianza. Esos supuestos deben registrarse junto con la protocol version, la fecha de la fuente y la policy, para que los cambios posteriores no se confundan con una garantía permanente.

Lecturas relacionadas

Otros artículos de Bitbase sobre este tema:

- Prueba de personalidad y resistencia a Sybil

- Transacciones privadas, shielded addresses y view keys

- Cómo se decide la elegibilidad para un airdrop: snapshots, puntos y filtros Sybil

Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en agosto de 2026; consulta la información oficial más reciente.