Términos Clave, Conceptos Fundamentales y Arquitecturas
Un protocolo criptográfico que permite a una parte (el "probador") demostrar a otra (el "verificador") la veracidad de una afirmación matemática sin revelar ninguna información subyacente más allá del hecho de que la afirmación es verdadera. Se cimienta en tres propiedades innegociables: completitud, solidez y cero conocimiento.
Información que el verificador recibe para especificar qué se demuestra: por ejemplo, un compromiso C o las raíces inicial y final de un estado. Las entradas públicas no quedan ocultas por usar una ZKP.
Datos que satisfacen una relación R(x,w)=1: una preimagen y su aleatoriedad, una credencial o la traza de ejecución de un circuito. El probador los utiliza para generar la prueba; el verificador no necesita recibirlos en claro.
Garantía formal de que un probador capaz de producir pruebas aceptadas posee un testigo adecuado, expresada mediante un extractor. Es una exigencia adicional respecto de rechazar afirmaciones falsas.
Un compromiso incorpora aleatoriedad privada para ocultar el valor antes de abrirlo y vincular al emisor con ese valor. La apertura entrega el valor y la aleatoriedad para verificar el compromiso. Por eso commit-reveal no es una ZKP, aunque sea útil como componente de otros protocolos.
Ocultación impide aprender el valor comprometido antes de su apertura. Vinculación impide abrir el mismo compromiso como dos valores diferentes. Dependen del esquema y sus supuestos; un hash de un mensaje predecible puede ser vulnerable a diccionario.
Cota sobre la probabilidad de aceptación indebida bajo las reglas del protocolo. En la cueva ideal se reduce por repetición independiente. No equivale a una probabilidad posterior sobre la honestidad de una persona.
Una prueba de validez certifica que las restricciones de un cálculo se cumplieron. Cero conocimiento protege el testigo respecto de la información pública. Un rollup puede utilizar pruebas de validez y publicar datos de transacciones; esas propiedades deben analizarse por separado.
Garantiza la fiabilidad del sistema para afirmaciones verdaderas. Formalmente, si un probador actúa honestamente y posee el conocimiento que respalda su afirmación, el protocolo asegura que el verificador aceptará la prueba. En la analogía de la "Cueva de Alí Babá", el probador que conoce la palabra secreta siempre puede salir por el camino que el verificador le solicita.
El pilar de seguridad que protege contra la falsificación. Dicta que si la afirmación es falsa, la probabilidad de engañar al verificador es probabilísticamente despreciable. En la cueva de Alí Babá, con desafíos binarios uniformes e independientes y una sesión de k rondas fijada de antemano, el error es (1/2)k. Esa fórmula no se aplica a cualquier sistema ZKP.
La propiedad de privacidad que asegura que la interacción no filtra información adicional sobre el secreto. El verificador aprende que el probador sabe algo, pero no aprende qué es ese algo.
Una evolución que elimina la necesidad de un diálogo entre probador y verificador. El probador genera una única "prueba" que puede ser verificada por cualquiera, en cualquier momento. Es fundamental para sistemas asíncronos como las blockchains y los ZK-rollups.
Una técnica que transforma un protocolo interactivo en uno no interactivo (NIZK) derivando los desafíos de un hash del contexto, la afirmación y el compromiso. Su seguridad exige las condiciones del protocolo y el modelo de oráculo aleatorio; no basta con agregar un hash arbitrario.
Se refiere a que la prueba es muy pequeña en tamaño y extremadamente rápida de verificar. Esta brevedad es fundamental para la escalabilidad en blockchain, permitiendo que una L1 verifique rápidamente la integridad de un lote masivo de transacciones de una L2.
Familia de sistemas ZK con pruebas muy pequeñas y verificación rápida (ej. Groth16, PLONK). Son la columna vertebral de muchos ZK-rollups, aunque a menudo requieren un "trusted setup".
Un sistema "transparente" que no requiere trusted setup. Son altamente escalables, resistentes a la computación cuántica, pero sus pruebas suelen ser de mayor tamaño.
Una variante de SNARK con un setup "universal y actualizable", lo que significa que una única ceremonia inicial sirve para muchos programas diferentes, haciéndolo muy flexible.
Un esquema SNARK con pruebas compactas y verificación eficiente basada en emparejamientos. Su desventaja es que requiere un trusted setup específico para cada circuito.
Pruebas de rango basadas en argumentos de producto interno, sin ceremonia de trusted setup. Su tamaño crece logarítmicamente con el rango; el costo de verificación también debe evaluarse.
Biblioteca y arquitectura de circuitos cuyo setup depende del esquema de compromisos utilizado. Las variantes IPA pueden ser transparentes; las variantes KZG requieren parámetros adecuados. El nombre Halo2 no garantiza por sí solo ausencia de ceremonia.
El proceso de traducir un programa computacional en un sistema de ecuaciones algebraicas (restricciones) que una ZKP puede entender. Es un paso de compilación esencial para generar una prueba.
Una ceremonia criptográfica para generar parámetros públicos (CRS) necesarios para algunos SNARKs. La seguridad depende de que los datos secretos intermedios ("residuo tóxico") se destruyan. Alternativas como las ceremonias multipartitas (MPC) o esquemas transparentes (por ejemplo, STARKs o sistemas con compromisos IPA) mitigan este riesgo.
Primitivas criptográficas clave: Compromiso para "sellar" un valor; Pruebas de Rango para demostrar que un valor está en un intervalo sin revelarlo; y Pruebas de Pertenencia para demostrar que un elemento está en un conjunto sin revelar cuál es.
La L1 (ej. Ethereum) es la capa de seguridad y consenso. La L2 es la capa de ejecución de alto rendimiento donde operan los ZK-rollups. La L2 hereda la seguridad de la L1.
El componente de la L2 que recibe, ordena y empaqueta las transacciones en lotes. La descentralización de este rol es un objetivo clave para la resistencia a la censura.
Un servicio computacionalmente intensivo que toma un lote de transacciones y genera la ZK-proof correspondiente. Su costo se amortiza entre todas las transacciones del lote.
Un contrato inteligente en la L1 diseñado para una tarea: verificar la validez de las pruebas ZK. Si es válida, actualiza la raíz de estado del rollup.
La garantía de que los datos para reconstruir el estado de la L2 están públicos. Hay dos modelos:
El conjunto de contratos que gestiona el depósito y retiro seguro de activos entre la L1 y la L2. No se requiere el período de disputa propio de un optimistic rollup, pero los retiros dependen de la generación y publicación de pruebas, la inclusión y finalidad en L1, la disponibilidad de datos y las reglas del puente.
Un conjunto de transacciones de L2 que se agrupan, ejecutan y prueban juntas. El procesamiento por lotes es la clave de la eficiencia de los rollups.
La finalidad de una transición requiere la aceptación de su prueba, la inclusión en L1 y la finalidad de esa cadena. El tiempo hasta esa condición incluye espera del lote, generación y publicación de la prueba y las etapas de L1; no debe confundirse con una confirmación del secuenciador.
TPS (Transacciones por Segundo) es la medida del rendimiento. El Fee Amortizado es un costo medio del lote: costo total considerado dividido por número de transacciones. La comisión efectiva del usuario también puede incluir ejecución en L2, generación de pruebas, margen del operador y condiciones del mercado de datos.
Un compromiso de diseño: lotes más grandes aumentan el throughput (TPS) y reducen el fee, pero pueden aumentar la latencia si la red tiene poco tráfico, ya que se debe esperar a que el lote se llene.
Los Optimistic Rollups asumen validez y usan "pruebas de fraude" con un período de disputa (retiros lentos). Los ZK-rollups usan pruebas de validez sin ese período de disputa; su liquidación y retiros dependen de pruebas, datos, contratos y finalidad en L1.
Un rollup que replica el entorno de ejecución de Ethereum (EVM) dentro de un circuito ZK, permitiendo portar dApps y herramientas de Ethereum a la L2 con mínimos cambios.
Aplicaciones avanzadas: zk-ID para probar atributos personales sin revelar datos; Proof of Reserves (PoR) para demostrar reservas bajo un alcance definido; afirmar solvencia exige además considerar pasivos, integridad de los datos y otros supuestos; y sistemas Anti-trampa en juegos para verificar acciones sin revelar la lógica interna.
En SNARKs con trusted setup, un fallo en la ceremonia inicial podría comprometer la seguridad. Además, las actualizaciones de los contratos deben ser manejadas con extrema cautela a través de una gobernanza robusta.
El principal riesgo de los sistemas Validium. Si el comité encargado de los datos se vuelve malicioso o falla, los usuarios podrían ser incapaces de acceder a sus fondos.
Debido a su complejidad, todos los componentes de un sistema ZK deben ser sometidos a rigurosas auditorías y monitoreo continuo para proteger el sistema contra posibles ataques.
Lenguajes especializados como Circom, Noir, o Cairo que permiten escribir la lógica computacional a probar y compilarla al formato que los sistemas ZKP entienden.
Bibliotecas como snarkjs y los SDKs de plataformas como zkSync, Polygon zkEVM y Starknet, que facilitan la construcción de aplicaciones sobre estas L2.
Funciones de hash como Poseidon o Rescue, diseñadas para ser representadas de manera muy eficiente dentro de un circuito ZK, minimizando el costo de generar una prueba.