Crash Course: Privacidad y Confianza Digital con DIDs, VCs y Zero-Knowledge Proofs

Objetivo General

Comprender la arquitectura fundamental de la Identidad Descentralizada y cómo las Pruebas de Conocimiento Cero (ZKPs) permiten la verificación de atributos y acciones garantizando la privacidad absoluta del usuario, así como comprender el contexto socio-tecnológico, de financiamiento y de licencias que impulsa su desarrollo, sentando las bases para construir un Estándar Regional de Certeza Digital transfronterizo.

Índice

• Módulo 1: Fundamentos de la Identidad Descentralizada (SSI)
  • Objetivo: Entender por qué el modelo actual de identidad está roto y cómo DIDs y VCs lo solucionan.
    • Evolución de la Identidad Digital: De los modelos centralizados (silos) y federados (Google/Facebook Login) al modelo descentralizado (SSI).
    • Identificadores Descentralizados (DIDs): 
      • ¿Qué son? (Estándar W3C).
      • Estructura básica: `did:method:specific-id`.
      • Resolución de un DID a un Documento DID (claves públicas y endpoints).
• Credenciales Verificables (VCs):
  • El Triángulo de la Confianza: Emisor (Issuer), Titular (Holder) y Verificador (Verifier).
  • Estructura de una VC (Metadatos, Claims o afirmaciones, y Firma Criptográfica).
• Módulo 2: Introducción a Zero-Knowledge Proofs (ZKP)
  • Objetivo: Desmitificar la criptografía ZK y entender sus propiedades fundamentales sin entrar en matemáticas profundas.
  • ¿Qué es una Prueba de Conocimiento Cero?
    • Definición: Demostrar que una afirmación es cierta sin revelar ninguna información adicional.
    • Actores: El Probador (Prover) y el Verificador (Verifier).

Las Tres Propiedades Fundamentales:

• Completitud (Completeness)
• Solidez (Soundness)
• Conocimiento Cero (Zero-Knowledge)

Analogías Didácticas: El juego de "¿Dónde está Wally?"

Tipos de ZKPs en la industria: Breve mención de zk-SNARKs y zk-STARKs (diferencias en tamaño de prueba y necesidad de configuración inicial o Trusted Setup).

• Módulo 3: El Stack Integrado (DIDs + VCs + ZKPs)
  • Objetivo: Conectar la identidad con la privacidad criptográfica, analizando la arquitectura de confianza y sus posibles vectores de vulnerabilidad.
    • Limitaciones de las VCs tradicionales: Riesgo de correlación y sobreexposición de datos (ej. mostrar todo el pasaporte solo para probar la mayoría de edad).
    • Divulgación Selectiva (Selective Disclosure): Cómo revelar solo ciertos atributos de una credencial (ej. firmas BBS+).
  • Predicados ZKP (ZK-Predicates)
    • Probar condiciones sobre un dato sin revelar el dato.
    • Ejemplo clásico: Probar "Edad > 18" sin revelar la fecha de nacimiento exacta.
  • AnonCreds (Anonymous Credentials): Uso histórico e implementación en frameworks como Hyperledger Aries.
  • El Papel de los Oráculos en la Arquitectura
    • Definición: Puentes de información que conectan el mundo exterior (*off-chain*) con los registros verificables o contratos inteligentes (*on-chain*).
    • El "Problema del Oráculo" (Oracle Problem): Identificación de anclas de vulnerabilidad. La criptografía ZKP prueba que un cálculo se hizo correctamente sobre un dato, pero no prueba que el dato original fuera real ("Garbage in, garbage out").
    • Mitigación de Riesgos: Oráculos descentralizados (ej. redes de consenso de datos) vs. Oráculos centralizados (puntos únicos de fallo o *Single Points of Failure*).
• Módulo 4: Casos de Uso y Aplicaciones Prácticas
  • Objetivo: Aterrizar los conceptos en arquitecturas reales.
  • Cumplimiento Normativo (KYC/AML) Privado: Demostrar que un usuario no está en una lista negra sin revelar su identidad a terceros.
  • Voto Electrónico Anónimo: Demostrar el derecho al voto (estar en el padrón) y que no se ha votado antes, sin vincular el voto a la identidad.
  • Acceso a Servicios y Finanzas Descentralizadas (DeFi): Pruebas de solvencia o historial crediticio sin exponer el balance total.
• Módulo 5: Ecosistemas, Gobernanza y el Motor de la Innovación
  • Objetivo: Comprender el contexto actual del desarrollo tecnológico, el rol del código abierto (open-source) y cómo interactúan las infraestructuras públicas, federadas y privadas.
  • Tipos de Ecosistemas y Gobernanza:
    • Ecosistemas Privados: Redes corporativas cerradas (silos empresariales). Priorizan el control, pero carecen de interoperabilidad.
    • Ecosistemas Públicos (Permissionless): Redes abiertas como Ethereum. Actúan como laboratorios globales de innovación sin barreras de entrada.
    • Ecosistemas Federados (Consorcios): Redes permisionadas operadas por nodos de confianza (ej. el Estado, universidades, bancos). Ideales para infraestructura pública digital con cumplimiento normativo (ej. EBSI en Europa o LACChain en Latinoamérica).
  • El Ciclo de Innovación Abierta y Licenciamiento
    • El poder de las licencias permisivas (MIT, Apache 2.0).
    • Cómo la investigación y desarrollo (I+D) financiada y probada en ecosistemas públicos (Web3) puede ser adoptada e implementada de forma segura por ecosistemas federados (el Estado) sin depender de proveedores monopólicos (vendor lock-in).
  • Economía del Desarrollo ZKP y el Rol del Venture Capital:
    • Breve contexto histórico: La teoría ZKP nació en la academia en 1985 (MIT/IBM), pero fue la explosión de ecosistemas públicos la que justificó su desarrollo práctico.
    • Financiamiento de la innovación: Cómo los Venture Capitals (VC) fondean el ecosistema cripto/público, permitiendo la creación de herramientas de bienes públicos digitales (Public Goods).
    • La evolución de los lenguajes ZK: De CIRCOM (que abstrajo la complejidad matemática inicial) a ecosistemas modernos como Starknet (con su lenguaje Cairo) y Aztec (con Noir), que permiten escribir programas probables con la facilidad de la programación tradicional.

Desarrollo del Curso: Privacidad y Confianza Digital

Módulo 1: Fundamentos de la Identidad Descentralizada (SSI)

La Evolución de la Identidad Digital

El modelo de identidad en internet no fue diseñado con una capa nativa para las personas, lo que derivó en tres grandes paradigmas:

• Modelo Centralizado (Silos): Cada sitio web requiere un usuario y contraseña. Genera fatiga de contraseñas, bases de datos vulnerables (honeypots) y pérdida de control por parte del usuario.
• Modelo Federado (IdP - Identity Providers): Empresas como Google o Facebook actúan como proveedores de identidad (mediante protocolos como OAuth2 o SAML). Aunque mejora la experiencia del usuario, crea monopolios de datos y permite a estas corporaciones rastrear la actividad del usuario en toda la red.
• Modelo Descentralizado (Self-Sovereign Identity - SSI): El usuario recupera la soberanía sobre sus datos. No depende de un proveedor central; la confianza se establece mediante criptografía asimétrica y redes descentralizadas.

Identificadores Descentralizados (DIDs)

Un DID es un estándar del W3C (World Wide Web Consortium). A diferencia de un correo o un nombre de usuario, un DID es un identificador único global que no depende de un registro centralizado.

Estructura: Sigue el formato URI `did:method:specific-id` (ej. `did:polygonid:2qQ68J...`).

Universal Resolver

Resolución: Un DID se resuelve criptográficamente hacia un Documento DID. Este documento es público y contiene las claves públicas del usuario y los Service Endpoints* (dónde y cómo comunicarse con él), permitiendo que cualquiera verifique firmas emitidas por ese DID sin depender de un servidor central.

Credenciales Verificables (VCs)

Las VCs son el equivalente digital y criptográficamente seguro de los documentos físicos (DNI, título universitario).

La credencial verificable, en este caso, es llamada "Peranto ID MX 1", la cual es un 1:1 de los datos de la INE mexicana. Peranto funciona como el Emisor, en el caso ideal tendría que ser el INE o cualquier institución de confianza nacional o privada que pueda atestiguar la veracidad de una información.

El holder en este caso es el ciudadano o propietario de esta credencial que solo vive del lado del ciudadano. El registro de estas credenciales se realiza en cadena, y la criptografía de firmas digitales queda del lado del usuario/ciudadano; esto sucede gracias a las infraestructuras de clave pública que nativamente operan con criptografía asimétrica al igual que la seguridad en las cadenas de bloques.

En la imagen se muestra la firma sobre un documento PDF y son esos datos con los que firmó el ciudadano. En este caso, la información puede ser leída y almacenada por terceros ajenos a la información; sin embargo, para acciones críticas sobre la cuenta que ha firmado, no es posible sin la clave privada y esta información solo queda como verificabilidad, pruebas, cadenas de custodia, etc.

La privacidad por diseño en este caso no permite privacidad al 100%, pero sí demuestra consentimiento. Esto se debe a que sabemos la información de mi firma porque un Verificador lo ha resuelto de forma local y verificado en cadena; de esta forma se cierra el círculo o flujo de las tres entidades.

Operan bajo el Triángulo de la Confianza:

• Emisor (Issuer): Una entidad confiable (ej. una universidad o el Estado) que firma criptográficamente una afirmación sobre alguien.
• Titular (Holder): El usuario que recibe, guarda en su wallet (billetera digital) y controla la VC.
• Verificador (Verifier): Un tercero que solicita pruebas de la credencial. Verifica la firma del Emisor usando su DID público, sin necesidad de contactar al Emisor directamente.

Módulo 2: Introducción a Zero-Knowledge Proofs (ZKP)

¿Qué es una Prueba de Conocimiento Cero?

Inventadas en 1985 por Shafi Goldwasser, Silvio Micali y Charles Rackoff, las ZKPs son protocolos criptográficos que permiten a una parte (el Probador o Prover) demostrar a otra parte (el Verificador o Verifier) que una afirmación es matemáticamente cierta, sin revelar absolutamente ninguna información adicional más allá de la veracidad de la afirmación.

Las Tres Propiedades Fundamentales

Para que un protocolo sea considerado ZK, debe cumplir rigurosamente tres axiomas matemáticos:

• Completitud (Completeness): Si la afirmación es cierta, un Probador honesto siempre podrá convencer a un Verificador honesto.
• Solidez (Soundness): Si la afirmación es falsa, es matemáticamente inviable que un Probador engañoso convenza al Verificador (la probabilidad de engaño es estadísticamente despreciable).
• Conocimiento Cero (Zero-Knowledge): El Verificador no aprende nada sobre los datos subyacentes. Si el Verificador graba la interacción, no puede usar esa grabación para convencer a un tercero.

Analogía Didáctica: ¿Dónde está Wally?

Imagina que quieres probar a un amigo que sabes dónde está Wally en un póster gigante, pero te niegas a señalar el lugar exacto. Tomas una cartulina negra gigante, le haces un pequeño agujero y la colocas sobre el póster de manera que solo la figura de Wally sea visible a través del agujero. 

Tu amigo ve a Wally, por lo que está convencido de que lo encontraste (Completitud y Solidez).

Como la cartulina negra tapa todo el contexto (no se ve si está en la playa o en la ciudad), tu amigo no aprende las coordenadas de Wally (Conocimiento Cero).

Tipos de ZKPs en la industria

   zk-SNARKs: (Argumentos de conocimiento sucintos y no interactivos). Son las más usadas hoy en día. Las pruebas son pequeñísimas y rápidas de verificar, pero históricamente requieren un Trusted Setup* (una ceremonia criptográfica inicial).

   zk-STARKs: (Escalables y transparentes). No requieren Trusted Setup* y son resistentes a la computación cuántica, pero el tamaño de la prueba es más pesado, lo que consume más ancho de banda.

Módulo 3: El Stack Integrado (DIDs + VCs + ZKPs)

El problema de la sobreexposición y la Divulgación Selectiva

Cuando presentas un DNI físico para entrar a un bar, el guardia no solo verifica que eres mayor de edad; también ve tu nombre completo, dirección y fecha de nacimiento exacta. Esto es sobreexposición. 

Para solucionarlo, hay ecosistemas que utilizan esquemas de firma criptográfica avanzada como BBS+ sobre las Credenciales Verificables.

BBS+ permite la **Divulgación Selectiva**: el *Holder* puede decidir compartir solo su nombre y ocultar su dirección, y el *Verifier* aún puede comprobar matemáticamente que la firma original del Emisor no ha sido alterada.

Predicados ZKP (ZK-Predicates)

Llevando la privacidad al extremo, podemos usar ZKPs sobre Credenciales Verificables. En lugar de revelar la fecha de nacimiento real, el Holder genera una prueba criptográfica local en su teléfono que responde a la pregunta lógica: ¿Es la Fecha_Nacimiento < 2006? 

El Verificador solo recibe un `TRUE` o `FALSE` matemático. Esto elimina por completo el riesgo de correlación de datos y robo de identidad. Herramientas como AnonCreds (usadas en Hyperledger Aries) han sido pioneras en este estándar.

El Papel de los Oráculos y la Arquitectura de Confianza

A nivel arquitectónico, la criptografía no resuelve la veracidad del mundo físico. Aquí entran los Oráculos: puentes que inyectan datos del mundo exterior (off-chain) hacia los sistemas verificables (on-chain).

El Problema del Oráculo: La criptografía ZKP garantiza que un cálculo se hizo perfectamente sobre un dato. Pero si el dato original era falso (ej. una universidad emite un título a un estudiante que no cursó materias), la ZKP certificará una mentira de forma matemáticamente perfecta ("Garbage in, garbage out"*).

La analogía del Notario Ciego: Las ZKPs actúan como un notario ciego que certifica que un documento tiene un sello oficial, pero no puede leer si el contenido es un fraude. Por ende, los Oráculos y los Emisores de VCs son las anclas de vulnerabilidad. La mitigación requiere gobernanza humana, auditorías e infraestructuras de oráculos descentralizados que consensuen la verdad antes de anclarla criptográficamente.

Ejemplos Actuales de Oráculos y Anclas de Confianza (Ideales):

• Oráculos Web3: Redes descentralizadas como Chainlink (que inyectan precios financieros fidedignos a contratos inteligentes) o protocolos como zkPass y TLSNotary, que actúan como oráculos de privacidad permitiendo exportar datos de portales Web2 (ej. tu banco tradicional) hacia Web3 usando ZKPs.
• Oráculos Institucionales (El Estado como Ancla): Infraestructuras de clave pública (PKI) como la e.firma (antes FIEL) en México o la Firma Electrónica Avanzada en Chile. En este modelo, el Estado actúa como un oráculo centralizado de máxima autoridad: da fe de la identidad física de un ciudadano en el mundo real y emite un certificado criptográfico que sirve como raíz de confianza para emitir Credenciales Verificables posteriores.

Módulo 4: Casos de Uso y Aplicaciones Prácticas

Cumplimiento Normativo (KYC/AML) Privado

Históricamente, los procesos de Know Your Customer (KYC) y Prevención de Lavado de Dinero (AML) obligan a los usuarios a entregar copias de sus pasaportes a múltiples plataformas, creando bases de datos altamente vulnerables a hackeos. 

   La solución con ZKP: Un usuario realiza el KYC una sola vez con una entidad regulada (el Emisor/Oráculo). Esta entidad le emite una Credencial Verificable. Cuando el usuario desea acceder a un exchange o servicio financiero (el Verificador), genera una prueba ZKP que demuestra matemáticamente: "Soy ciudadano de una jurisdicción permitida y no estoy en la lista negra de la OFAC"*, sin revelar su nombre, número de documento ni país exacto.

Voto Electrónico Anónimo y Resistente a la Coerción

El gran desafío del voto digital es garantizar dos propiedades aparentemente contradictorias: la elegibilidad (solo pueden votar los empadronados, una sola vez) y el secreto (nadie debe saber por quién votó).

   La solución con ZKP: Mediante la emisión de un token de voto ciego o una VC de empadronamiento, el ciudadano genera una prueba ZKP que se envía a la urna digital. La prueba afirma: "Poseo una credencial válida emitida por el tribunal electoral y no he emitido una prueba previamente con esta credencial"*. La urna verifica la validez del voto y lo suma, pero la criptografía impide correlacionar la boleta con la identidad pública del votante.

Finanzas Descentralizadas (DeFi) y Pruebas de Solvencia

En el sistema financiero tradicional, pedir un préstamo sin colateral requiere exponer todo el historial crediticio (Buró de Crédito).

   La solución con ZKP: Un usuario puede solicitar un préstamo demostrando que su score* crediticio es mayor a 700 o que sus ingresos mensuales superan un umbral específico, utilizando un oráculo que conecte su cuenta bancaria mediante ZKP. El prestamista (Verificador) obtiene la certeza de solvencia sin acceder a los estados de cuenta detallados del prestatario.

Módulo 5: Ecosistemas, Gobernanza y el Motor de la Innovación

Tipos de Ecosistemas y Gobernanza

El desarrollo de la identidad descentralizada no ocurre en un vacío; depende del tipo de red sobre la que se despliegue:

• Ecosistemas Privados: Redes corporativas cerradas (silos empresariales). Priorizan el control absoluto y la privacidad interna, pero sufren de falta de interoperabilidad. Son útiles para intranets corporativas.
• Ecosistemas Públicos (Permissionless): Redes abiertas como Ethereum o Polygon. Actúan como laboratorios globales de innovación sin barreras de entrada. Son altamente resilientes, pero su naturaleza pública requiere que la privacidad (ZKP) se gestione fuera de la cadena (off-chain*).
• Ecosistemas Federados (Consorcios): Redes permisionadas operadas por nodos de confianza legalmente vinculantes (ej. el Estado, universidades, bancos centrales). Son el punto intermedio ideal para infraestructura pública digital con cumplimiento normativo. Ejemplos actuales incluyen EBSI en Europa o LACChain en Latinoamérica.

El Ciclo de Innovación Abierta y Licenciamiento

La adopción masiva de SSI y ZKP por parte de los gobiernos sería imposible sin el software de código abierto (open-source). 

   Licencias Permisivas: El uso de licencias como MIT o Apache 2.0 permite que cualquier entidad audite, bifurque (fork*) y mejore el código. 

   Evitando el Vendor Lock-in*: Históricamente, los Estados dependían de proveedores tecnológicos monopólicos. Hoy, la I+D financiada y probada en ecosistemas públicos (Web3) puede ser adoptada e implementada de forma soberana por ecosistemas federados (el Estado). Si un proveedor falla, el Estado puede cambiarlo sin perder la infraestructura subyacente, ya que el código y los estándares (W3C) son abiertos.

Economía del Desarrollo ZKP y el Rol del Venture Capital

Para entender la madurez de esta tecnología, es vital comprender su economía política:

• De la Academia al Mercado: La teoría ZKP nació en la academia en 1985 (MIT/IBM), pero requería demasiado poder de cómputo. Pasó décadas inactiva hasta que la explosión de ecosistemas criptográficos públicos justificó la inversión en su desarrollo práctico.

   La "Fórmula 1" de la Tecnología: Los ecosistemas públicos y los Venture Capitals (VC) funcionan como la Fórmula 1: un entorno de alto riesgo y experimentación extrema que fondea la creación de bienes públicos digitales (Public Goods*).

La Evolución de los Lenguajes ZK (CIRCOM, Cairo y Noir): El primer gran catalizador fue CIRCOM (creado por Jordi Baylina), que abstrajo la complejidad matemática profunda para compilar circuitos ZK. Hoy, la innovación financiada por capital de riesgo ha evolucionado hacia ecosistemas más robustos orientados a la escalabilidad y la privacidad nativa:

- Starknet y Cairo: Starknet es una red pública de capa 2 (ZK-Rollup) diseñada para escalar Ethereum utilizando zk-STARKs. Su lenguaje de programación nativo, Cairo, es Turing-completo y permite a los desarrolladores escribir programas complejos y "probables" (*provable programs*) sin necesidad de ser criptógrafos.

- Aztec y Noir: Aztec es una red enfocada en la privacidad por defecto. Su lenguaje, Noir, utiliza una sintaxis muy similar a Rust y busca ser un estándar universal (un DSL o *Domain-Specific Language*) para crear ZKPs de manera altamente intuitiva, ocultando por completo la complejidad del *backend* criptográfico. Esta maduración tecnológica es la que hoy elimina las barreras de entrada, permitiendo que bancos, desarrolladores estándar e instituciones estatales adopten ZKPs para proteger la privacidad ciudadana a gran escala.

Módulo 6: Hacia un Estándar Regional de Certeza Digital

Objetivo: Proyectar la adopción de DIDs, VCs y ZKPs más allá de los casos aislados, entendiendo cómo estas tecnologías permiten construir un marco de interoperabilidad transfronteriza, validez jurídica y soberanía ciudadana.

El Reto de la Interoperabilidad Transfronteriza

Actualmente, la "certeza digital" termina en la frontera de cada país. Una firma electrónica o un título universitario validado en México o Chile requiere procesos burocráticos (como la apostilla de La Haya) para ser reconocido en otro país. 

   La Solución SSI: Al utilizar estándares globales del W3C (DIDs y VCs), la infraestructura técnica se vuelve un lenguaje universal. Un ciudadano puede portar sus credenciales en su wallet* y presentarlas en cualquier país de la región, garantizando que los datos son inmutables y verificables instantáneamente.

Marcos y Registros de Confianza (Trust Registries)

La tecnología resuelve la verificación criptográfica, pero no la confianza institucional. ¿Cómo sabe un Ministerio de Educación en Colombia que el DID que firmó un título realmente pertenece a la UNAM en México?

• La Capa Institucional: Un Estándar Regional requiere la creación de Registros de Confianza (Trust Registries). Estos son directorios descentralizados (operados por consorcios federados) donde los Estados publican los DIDs oficiales de sus instituciones autorizadas. Así, se crea una red de validación cruzada donde la criptografía ZKP protege al ciudadano, y el Registro de Confianza da certeza jurídica al verificador.

Armonización Regulatoria (Inspiración Global)

Para que la Certeza Digital sea una realidad, la tecnología debe ir acompañada de regulación.

   El Modelo eIDAS 2.0: En Europa, el marco eIDAS 2.0 está obligando a los Estados miembros a proveer Identity Wallets* a sus ciudadanos, estandarizando el uso de VCs y ZKPs para acceso a servicios públicos y privados en toda la Unión Europea.

• El Potencial Regional: Iniciativas como LACChain en América Latina o marcos de la OEA buscan replicar este modelo. El objetivo es que las infraestructuras de clave pública (PKI) existentes (como la e.firma) evolucionen para convertirse en emisores nativos de Credenciales Verificables, logrando que la identidad digital sea un bien público regional.

Soberanía Tecnológica y el Ciudadano en el Centro

Un "Estándar Regional" no debe depender de corporaciones tecnológicas extranjeras (Big Tech). Utilizar infraestructura pública (Ethereum/Polygon) o federada con software de código abierto (MIT/Apache) garantiza Soberanía Tecnológica.

El objetivo final de la Certeza Digital es empoderar al usuario: devolverle la propiedad de sus datos, proteger su privacidad (ZKP) y garantizarle acceso sin fricciones a sus derechos civiles, financieros y educativos en toda la región.

Bibliografía y Fuentes de Referencia

Para profundizar en los estándares, fundamentos matemáticos y marcos regulatorios que sustentan este curso, se recomienda la siguiente bibliografía primaria:

Sobre Identificadores Descentralizados (DIDs):

    W3C (2022). Decentralized Identifiers (DIDs) v1.0. Core architecture, data model, and representations.* World Wide Web Consortium Recommendation. Recuperado de: https://www.w3.org/TR/did-core/

Sobre Credenciales Verificables (VCs):

    W3C (2025). Verifiable Credentials Data Model v2.0.* World Wide Web Consortium Recommendation. Recuperado de: https://www.w3.org/TR/vc-data-model-2.0/

Sobre Pruebas de Conocimiento Cero (ZKP):

    Goldwasser, S., Micali, S., & Rackoff, C. (1989). The knowledge complexity of interactive proof systems.* SIAM Journal on Computing, 18(1), 186-208. (Publicación original presentada en FOCS 1985).

Sobre Marcos Regulatorios e Identidad Regional:

    Comisión Europea (2024). Regulation (EU) 2024/1183 (eIDAS 2.0)*. Marco legal para una identidad digital europea segura e interoperable (European Digital Identity Wallet). Diario Oficial de la Unión Europea.

Evaluación de Comprensión (Test Rápido)

Instrucciones: Este breve cuestionario permite validar la asimilación de los conceptos clave del curso.

En el "Triángulo de la Confianza" de las Credenciales Verificables (VCs), ¿cuál es el rol del Verificador?

a) Almacenar la credencial en una wallet y decidir cuándo compartirla.

b) Emitir la credencial y firmarla criptográficamente.

c) Comprobar la firma criptográfica del Emisor usando su DID público, sin contactarlo directamente.

d) Inyectar datos del mundo físico hacia la blockchain.

(Respuesta correcta: c)

¿Cuáles son las tres propiedades matemáticas inquebrantables de una Prueba de Conocimiento Cero (ZKP)?

a) Completitud, Solidez y Conocimiento Cero.

b) Descentralización, Escalabilidad y Seguridad.

c) Anonimato, Inmutabilidad y Velocidad.

d) Emisor, Titular y Verificador.

(Respuesta correcta: a)

En la arquitectura SSI, ¿qué problema fundamental introducen los Oráculos?

a) Consumen demasiado ancho de banda de la red.

b) "Garbage in, garbage out": Si el dato original inyectado por el oráculo es falso, la ZKP certificará una mentira de forma perfecta.

c) Requieren un Trusted Setup que compromete la privacidad.

d) No son compatibles con los estándares del W3C.

(Respuesta correcta: b)

¿Por qué es fundamental el uso de software de código abierto y licencias permisivas (ej. MIT) en la creación de un Estándar Regional de Certeza Digital?

a) Porque es la única forma de cobrar regalías a los ciudadanos.

b) Para evitar el vendor lock-in (dependencia de proveedores monopólicos) y garantizar la Soberanía Tecnológica del Estado.

c) Porque las corporaciones tecnológicas (Big Tech) prohíben el uso de ZKPs.

d) Para que las redes públicas eliminen la necesidad de oráculos.

(Respuesta correcta: b)

¿Qué es un "Registro de Confianza" (Trust Registry) en el contexto de la interoperabilidad transfronteriza?

a) Un servidor centralizado propiedad de una empresa privada que guarda las contraseñas de los usuarios.

b) El lenguaje de programación nativo de Starknet.

c) Un directorio descentralizado donde los Estados publican los DIDs oficiales de sus instituciones autorizadas para dar certeza jurídica a las credenciales.

d) Una Prueba de Conocimiento Cero que oculta la identidad de los gobiernos.

(Respuesta correcta: c)