Pruebas de Conocimiento Cero en Web3: Qué es ZK-SNARK

Si analizamos Web3 a través de casos de uso aplicados, tarde o temprano nos encontramos con el mismo problema: una cadena de bloques es, por definición, transparente, mientras que la mayoría de las tareas del mundo real requieren privacidad. Hay que demostrar que una transacción, un cálculo o un estado son correctos, pero al mismo tiempo no se quieren revelar los datos subyacentes a todo el mundo. Es en esta intersección donde aparecen las Pruebas de Conocimiento Cero y, más concretamente, ZK-SNARK como uno de los instrumentos clave de la tecnología de conocimiento cero.

En los últimos años, las Pruebas de Conocimiento Cero han dejado de ser una construcción teórica para convertirse en una capa operativa de la infraestructura Web3. Se utilizan para lanzar pagos privados y protocolos de identidad, construir rollups ZK para el escalado de Ethereum, verificar la corrección de operaciones complejas sin revelar datos en bruto y reforzar la seguridad de Web3 allí donde la simple transparencia de la cadena de bloques ya no es suficiente. Como resultado, SNARK, así como STARK y la aparición de nuevos sistemas ZK-Proof, dejan de ser temas puramente académicos: la forma en que se construye esta capa determina directamente lo seguras, privadas y escalables que serán realmente las redes y los protocolos a los que asignes capital.

Obtenga nuestro desglose detallado sobre Fundamentos DeFi: Guía para principiantes de las finanzas descentralizadas (2025)

Stack 10% More on Your First BTCC Deposit

Start Trading

Pruebas de conocimiento cero en Web3: ideas básicas y por qué son importantes

Antes de sumergirnos en la implementación técnica, que sin duda merece su atención, veamos la idea central que hay detrás y qué problemas pretende resolver.

¿Qué es una prueba de conocimiento cero?

Una prueba de conocimiento cero es una prueba criptográfica que permite confirmar la exactitud de una afirmación sin revelar los datos subyacentes en los que se basa. En lugar de publicar el conjunto completo de valores de entrada o los pasos intermedios del cálculo, el protocolo opera sobre una prueba compacta que es suficiente para comprobar si se han seguido las reglas prescritas.

Estos sistemas se basan en tres propiedades fundamentales:

• La integridad significa que, dados los datos correctos y el comportamiento honesto de la parte que genera la prueba, el verificador casi siempre acepta la prueba como válida.
• La solidez capta el lado opuesto: dada una declaración falsa, la probabilidad de generar una prueba que pase la verificación es extremadamente baja y despreciablemente cercana a cero.
• La propiedad de conocimiento cero garantiza que los datos ocultos no puedan reconstruirse a partir de la propia prueba y que no pueda extraerse ninguna información adicional sobre ellos; la única conclusión de que dispone el verificador es que la declaración satisface las condiciones formalizadas del protocolo.

Así pues, las pruebas de conocimiento cero constituyen una clase aparte de pruebas criptográficas rigurosas, comparables en su nivel de formalidad a las firmas digitales, los compromisos y otras primitivas fundamentales. Pueden describirse, implementarse y analizarse en los mismos términos que el resto de la criptografía básica sobre la que se construyen los sistemas blockchain.

De las pruebas criptográficas a los sistemas a prueba de ZK

Los mecanismos criptográficos clásicos resuelven diferentes problemas. Las firmas confirman la autoría de un mensaje y su inmutabilidad, pero el contenido en sí permanece abierto. Las funciones hash permiten comprometerse con un valor y demostrar posteriormente que se ha utilizado exactamente ese valor, pero los datos subyacentes se revelan durante la verificación. La autenticación interactiva y los protocolos de verificación del conocimiento requieren repetidos intercambios de mensajes entre las partes y se adaptan mal a entornos en los que muchos nodos independientes deben verificar el mismo hecho.

Las pruebas de conocimiento cero añaden otro tipo de prueba, en la que la verificabilidad se separa de la revelación de datos y no requiere un diálogo interactivo obligatorio. Basándose en esta idea, se forman familias de sistemas ZK-Proof, protocolos concretos de conocimiento-cero que difieren en su fundamento matemático, supuestos criptográficos, tamaño de la prueba, complejidad de generación y coste de verificación.

A la hora de elegir un sistema ZK-Proof concreto, los principales de los cuales examinaremos más adelante, se establecen las características arquitectónicas: qué recursos necesitarán los participantes de la red, qué nivel de confianza en los supuestos subyacentes es aceptable y qué parámetros de prueba y tiempo de verificación se ajustan a la carga objetivo. En este sentido, ZK-SNARK y ZK-STARK ocupan la posición de esquemas implementados por separado como dos entre muchas formas posibles de construir Pruebas de Conocimiento Cero; en realidad, el concepto permite un mayor número de variantes de implementación.

Por qué la tecnología de conocimiento-cero es importante para Web3

Ya sabes que las blockchains públicas proporcionan un estado único visible para todos: transacciones, balances, parámetros de protocolo y sus cambios están disponibles para su observación y verificación por cualquier nodo. Esto sin duda aumenta la resistencia a la manipulación de datos, pero al mismo tiempo convierte cada acción en parte de una historia abierta en la que las operaciones financieras, las estructuras de propiedad y el comportamiento de los participantes se vuelven fáciles de analizar. En muchos escenarios, esto entra en conflicto con los requisitos de privacidad, desde la protección de datos comercialmente sensibles hasta el cumplimiento de las normas reguladoras en determinadas jurisdicciones.

Aquí es exactamente donde la tecnología de conocimiento-cero llena el vacío, haciendo posible trasladar parte de las comprobaciones del nivel de revelación directa de los datos de entrada al nivel de verificación de la corrección de las reglas mediante una prueba criptográfica. Como resultado, la red sólo ve lo necesario para el consenso y las actualizaciones de estado, mientras que todos los parámetros sensibles permanecen bajo el control de las partes que los proporcionan. Este planteamiento crea una base para preservar tanto la confianza como la privacidad en Web3 que no está vinculada a una infraestructura de confianza ni a un almacenamiento centralizado, y abre el espacio para una privacidad verdaderamente descentralizada, en la que el control sobre la divulgación de la información se distribuye en lugar de concentrarse en un único operador.

También hay una ventaja adicional para la seguridad de Web3, porque parte de la lógica que antes vivía fuera de la cadena y se verificaba en un modelo basado en la confianza puede formalizarse en forma de sistemas ZK-Proof y verificarse a nivel de protocolo. Los nodos de la red adquieren la capacidad de verificar la corrección de las acciones según reglas uniformes sin ampliar el conjunto de datos de que disponen. En una arquitectura de este tipo, las Pruebas de Conocimiento Cero se convierten en una herramienta básica que permite combinar un libro de contabilidad abierto con la divulgación limitada y controlada de información sobre usuarios y procesos dentro del ecosistema.

¿Qué significa ZK-SNARK?

ZK-SNARK es un tipo específico de Prueba de Conocimiento Cero cuyo nombre codifica sus propiedades clave:

• Conocimiento Cero;
• Sucinta;
• No interactiva;
• Argumento de Conocimiento.

Conocimiento Cero indica que la prueba no revela los datos ocultos y no filtra ninguna información adicional sobre ellos más allá del hecho de que la afirmación es correcta. Sucinta significa que la prueba es de pequeño tamaño y que los nodos de la red pueden verificarla significativamente más rápido que el cálculo original que representa. No interactivo hace hincapié en que el prover genera la prueba una vez y el verificador puede comprobarla muchas veces sin ningún intercambio de mensajes adicional. Argumento de conocimiento fija el requisito de que un participante prácticamente nunca puede construir una prueba válida sin un conocimiento real del testigo oculto, es decir, los datos internos que hacen que la afirmación sea verdadera.

En conjunto, estas propiedades definen el perfil de ZK-SNARK como protocolo: pruebas compactas, verificación rápida, sin necesidad de diálogo interactivo y garantía criptográfica de que detrás de la prueba hay un conocimiento real y no una suposición aleatoria. Esta combinación hace de ZK-SNARK un candidato natural para su uso en redes blockchain en las que los nodos deben verificar un gran número de pruebas con recursos limitados.

Cómo funcionan los ZK-SNARK

La arquitectura de un ZK-SNARK se basa en varios roles y tipos de datos básicos. El prover genera la prueba y el verificador la comprueba. El prover describe la declaración como una declaración sobre entradas públicas - esta es la parte de la información que ven todos los participantes: resultados agregados, hashes de conjuntos de operaciones y parámetros que son importantes para el protocolo. La parte oculta que garantiza que la declaración es verdadera se suele denominar testigo; incluye valores privados, estados internos y cualquier dato que no deba acabar en el libro de contabilidad público.

• Los ingenieros suelen dividir el trabajo del esquema en varias etapas.
• En la etapa de configuración, generan los parámetros del sistema para el esquema y la clase de cálculos elegidos. En los ZK-SNARK clásicos, estos parámetros incluyen una configuración de confianza, y la seguridad de todas las pruebas posteriores depende directamente de lo correcta y honesta que sea la ejecución de este procedimiento por parte de los participantes.
• En la fase de generación de pruebas, el probador, dadas las entradas públicas y el testigo, construye una prueba de que los datos ocultos satisfacen todas las restricciones.
• En la fase de verificación ZK, el verificador, que sólo tiene las entradas públicas, la prueba y los parámetros del sistema, comprueba la exactitud de la prueba y no tiene acceso a los valores ocultos.

Un desarrollador no puede incrustar directamente un cálculo arbitrario en una ZK-SNARK. En su lugar, representan la lógica de una forma conveniente para la verificación, normalmente como circuitos aritméticos o un sistema de restricciones (circuitos/restricciones). Desglosan el cálculo en operaciones primitivas y las conexiones entre ellas, y el protocolo interpreta este conjunto como un sistema de condiciones que deben verificarse. Este enfoque permite formalizar y verificar funciones muy complejas, pero al mismo tiempo obliga a los desarrolladores a tener en cuenta el coste de cada operación en términos de sistemas ZK-Proof y a diseñar la lógica de modo que pueda traducirse eficazmente en circuitos sin un crecimiento excesivo del tamaño de las pruebas y de los recursos necesarios para su generación y verificación.

SNARK vs STARK: Comparación de sistemas ZK-Proof

Dentro de los sistemas a prueba de ZK, SNARK y STARK resuelven problemas similares, pero se basan en construcciones criptográficas diferentes y establecen distintas compensaciones para el protocolo. Los esquemas SNARK se basan en curvas elípticas fáciles de emparejar y en una cadena de referencia estructurada que los equipos obtienen una vez como resultado de una configuración de confianza para la clase de cálculos elegida.

Los esquemas STARK utilizan criptografía basada en hash, compromisos y protocolos de verificación especiales (por ejemplo, FRI) y los traducen a una forma no interactiva; los equipos no realizan una ceremonia de confianza independiente y aceptan un modelo de confianza basado en la dureza de las funciones hash y la corrección de la construcción del protocolo.

En términos de perfil de rendimiento, SNARK y STARK se comportan de forma diferente. Los esquemas SNARK proporcionan pruebas compactas y costes de verificación ZK casi constantes incluso a medida que crece la complejidad computacional, lo que se ajusta bien a las restricciones de gas y calldata en las redes en la capa Ethereum y en los rollups ZK. En los esquemas STARK, el tamaño de la prueba y los requisitos de ancho de banda crecen de forma más notable, pero el equipo puede escalar los cálculos pesados asignando comprobadores más potentes y manteniendo al mismo tiempo un nivel de seguridad estable a medida que aumenta la carga. Así, ya a nivel arquitectónico, algunos protocolos adoptan un perfil SNARK y minimizan el tamaño de la prueba y el coste de verificación, mientras que otros eligen deliberadamente un perfil STARK y pagan por ello con tráfico y almacenamiento adicionales.

En la práctica, estas diferencias determinan cómo los equipos diseñan y hacen evolucionar el protocolo. En los escenarios SNARK, fijan de antemano la clase de cálculos admitidos y adaptan a ella la configuración de confianza, las herramientas y la infraestructura del comprobador. En los escenarios STARK, construyen la pila en torno a un único esquema y lo escalan eligiendo la longitud de la traza del cálculo y los recursos asignados a la generación de pruebas. Como resultado, la elección entre SNARK y STARK se reduce al perfil del sistema ZK-Proof: qué primitivas está dispuesto a utilizar el equipo, qué volumen de datos y cálculos puede manejar la infraestructura de forma realista y con qué frecuencia tiene previsto ampliar o cambiar las clases de cálculos admitidos dentro del protocolo.

Obtenga nuestro desglose detallado sobre Crypto API: cómo funciona el espacio criptográfico bajo el capó

Stack 10% More on Your First BTCC Deposit

Start Trading

ZK-SNARKs en Web3: Privacidad y escalado de Ethereum

Veamos ahora con más detalle cómo contribuye ZK-SNARK no sólo a la seguridad y la privacidad, sino también al escalado de soluciones basadas en blockchain.

ZK-SNARK para la privacidad en Web3

Los protocolos que se basan en ZK-SNARK para la privacidad construyen el estado en torno a compromisos y anuladores en lugar de en torno a balances abiertos. El cliente forma un conjunto de datos de entrada ocultos, describe el cambio de estado deseado, calcula el testigo y crea una prueba de que la nueva configuración satisface todas las reglas. Sólo las raíces de los árboles, los hashes y los marcadores de servicio pasan al estado global, no los valores reales. Los nodos de la red leen la raíz actualizada y verifican el ZK-SNARK, pero no acceden a los parámetros internos del usuario. De este modo, la tecnología de conocimiento-cero traslada la comprobación de la corrección al nivel criptográfico y elimina la necesidad de revelar información sensible en el libro mayor compartido.

Una capa separada de lógica se encarga de decidir qué datos está dispuesto a revelar el propietario y a quién. A menudo se utilizan claves diferentes para las operaciones, la visualización del historial y las auditorías, y el formato de estado permite revelar elementos individuales sin revelar toda la estructura de propiedad y todos los pasos anteriores. Un usuario puede demostrar la propiedad de activos, la participación en una votación o el cumplimiento de una determinada condición sin mostrar su rastro completo de transacciones. Un auditor, tras recibir un acceso limitado, comprueba únicamente el conjunto de hechos que las partes consideran aceptables y se basa en los mismos sistemas ZK-Proof que los nodos de validación.

Con este diseño, la privacidad en Web3 deja de depender de un único operador o almacenamiento. Los nodos verificadores no deciden qué revelar; sólo validan las pruebas y actualizan el estado agregado. El control sobre la divulgación de datos lo tienen los propietarios de las claves correspondientes y las aplicaciones que elijan. Así es como se forma la privacidad verdaderamente descentralizada: el protocolo distribuye el control sobre el acceso a la información entre los participantes al tiempo que preserva el nivel general de verificabilidad que se espera de una blockchain pública.

Rollups ZK y escalado de Ethereum

En los rollups ZK, el equipo separa la ejecución y el consenso. La capa de ejecución acepta transacciones, les aplica la lógica del protocolo, mantiene un estado local y registra la traza de la ejecución. Tras una serie de operaciones, el operador recoge un lote, calcula la raíz del nuevo estado y genera un ZK-SNARK que vincula el estado antiguo y el nuevo mediante un sistema de restricciones. Junto con la prueba, el operador publica los datos mínimamente necesarios para la reconstrucción del estado en un contrato en la red base.

El contrato de rollup en Ethereum recibe el paquete, comprueba los formatos de los datos de entrada y ejecuta la verificación ZK. Si la prueba supera la verificación, el contrato acepta la nueva raíz como el estado actual de la capa y registra los cambios como parte del escalado de Ethereum. La mayor parte de la computación y el almacenamiento permanecen fuera de L1, mientras que la red base asume el papel de árbitro que sólo confirma la corrección de las transiciones de estado. Los parámetros del esquema ZK-SNARK elegido determinan cuántas transacciones cabe el operador en un lote, con qué frecuencia publica actualizaciones y qué parte de la tarifa final que paga el usuario procede del coste de verificación.

La verificación ZK establece requisitos para la infraestructura de rollup. Los nodos que rastrean L2 deben ser capaces de mantenerse al día con las pruebas entrantes y los datos asociados, y los clientes que reconstruyen el estado por su cuenta deben ser capaces de extraer los fragmentos necesarios de la información publicada. Si el equipo opta por un esquema con una generación de pruebas más pesada, traslada la carga principal a los operadores que construyen los lotes. Si opta por pruebas lo más compactas posible y una verificación ZK rápida, simplifica el trabajo de observadores y validadores, pero endurece los requisitos para implementar el esquema y optimizar la ejecución.

Dónde se utiliza hoy la tecnología de conocimiento-cero en Web3

La tecnología de conocimiento-cero ya ha formado varios tipos de soluciones bien establecidas en Web3. En un caso, los equipos diseñan una L1 para que funcione inicialmente con compromisos y ZK-SNARK: los formatos de transacción, la estructura de almacenamiento y los monederos de los clientes tienen en cuenta la necesidad de generar pruebas, almacenar claves de observación y gestionar estados privados. El usuario interactúa con la red a través de un cliente que recoge el contexto, forma el testigo y las pruebas, y la cadena sólo ve los valores agregados y los hashes.

En otro caso, se construyen capas independientes sobre las redes existentes. Estas soluciones aceptan transacciones, las ejecutan en su propio entorno, agregan los resultados y publican un ZK-SNARK más los datos necesarios para la reconstrucción del estado en un contrato en la red base. Los rollups ZK y los proyectos L2 relacionados utilizan este enfoque cuando quieren aumentar el rendimiento y reducir la carga L1 sin abandonar su modelo de consenso. El usuario sigue percibiendo que trabaja con el ecosistema Ethereum, pero una parte significativa del cálculo y la verificación se traslada a una capa adicional que depende de los sistemas ZK-Proof.

Una tercera dirección está siendo desarrollada por servicios que conectan múltiples redes y aplicaciones. Recopilan datos de diferentes fuentes, comprueban las condiciones localmente, construyen una ZK-SNARK para una declaración específica y pasan la prueba a un protocolo que toma una decisión. Estas construcciones se utilizan para la votación, la identidad, la prueba de solvencia y otros escenarios en los que es importante comprimir la información externa en una confirmación breve adecuada para la verificación en cadena.

En cada una de estas variantes, la elección de un sistema ZK-Proof concreto y el método de verificación ZK afectan directamente al nivel de privacidad en la Web3 que recibe el usuario, a los requisitos que la infraestructura impone a los nodos y al coste real de interactuar con protocolos que utilizan tecnología de conocimiento-cero.

Obtenga nuestro desglose detallado sobre la Interoperabilidad de Blockchain: El futuro de la comunicación entre cadenas

Web3 Seguridad y riesgos de la tecnología de conocimiento-cero

La tecnología de conocimiento-cero también cambia el modelo de amenazas de Web3. El protocolo deja de confiar únicamente en la honestidad del operador y en la corrección de la infraestructura y obliga a que cada paso significativo vaya acompañado de una prueba criptográfica estricta. El equipo fija el conjunto de invariantes que considera críticos y los traslada al espacio de los sistemas ZK-Proof. Mientras el prover genere pruebas correctamente y los nodos verificadores rechacen sistemáticamente todo lo que no pase la verificación, el protocolo mantiene la integridad del estado incluso en un entorno de ejecución parcialmente no fiable.

Este enfoque aporta varias ventajas directas a la seguridad de Web3. El equipo puede fijar las reglas de gestión de activos y estado de tal forma que los participantes no puedan saltárselas mediante cambios en el código local o en la configuración. Cualquier intento de salirse del esquema rompe la prueba o requiere comprometer las propias primitivas criptográficas. El protocolo obtiene un único criterio de comportamiento aceptable: los nodos no comprueban la motivación de los operadores, sino la conformidad de las acciones con las restricciones predefinidas. Los desarrolladores forman clases separadas de condiciones para los usuarios, la infraestructura y los auditores, y les adjuntan diferentes tipos de pruebas preservando el nivel común de verificabilidad.

Al mismo tiempo, la tecnología de conocimiento-cero introduce sus propios riesgos que no pueden ignorarse. En los esquemas con una configuración de confianza, el equipo crea y utiliza parámetros estructurados que actúan esencialmente como material clave para toda la vida posterior del protocolo. Si alguien conserva el acceso al secreto interno o viola el procedimiento de generación, adquiere la capacidad de emitir pruebas que pasan la verificación pero no reflejan la ejecución real de la regla. En un entorno con activos financieros, esto conlleva el riesgo de emisión oculta, elusión de límites o cambios de estado no autorizados. Un equipo que elige este modelo asume la responsabilidad del procedimiento de inicialización, su repetición y el manejo transparente de los parámetros.

La siguiente capa de riesgo está relacionada con la forma en que los desarrolladores describen la lógica en circuitos y la conectan al resto del sistema. Cada invariante omitida, índice intercambiado, comprobación de rango incorrecta o conjunto de entradas públicas incorrectamente formado se convierte en una vulnerabilidad que no puede ser compensada por la robustez de la red o la reputación del operador. Un observador externo sólo ve que la prueba pasa la verificación, pero no ve qué condiciones incluyó el equipo en el esquema y cuáles dejó fuera. Por lo tanto, cualquier sistema que se base en sistemas ZK-Proof requiere el mismo nivel de disciplina en el diseño y verificación de circuitos que en el desarrollo del núcleo del blockchain o el motor de la máquina virtual.

La auditoría plantea un reto aparte. El equipo debe proporcionar a los auditores contratos inteligentes, lógica de red, descripciones de circuitos, implementaciones de pruebas criptográficas, especificaciones de parámetros de seguridad y procesos de actualización. Cualquier cambio en las clases de cálculos admitidos, la profundidad de seguridad objetivo o la estructura de estado requiere un nuevo ciclo de análisis. El número de especialistas que pueden leer y verificar completamente tales construcciones es limitado, y cada iteración de auditoría debe planificarse en términos de tiempo y recursos. Si el equipo ignora este factor, despliega efectivamente un sistema cuyos fundamentos de seguridad son comprendidos por un estrecho círculo de desarrolladores, mientras que el resto de los participantes lo aceptan en confianza.

En consecuencia, la tecnología de conocimiento cero refuerza la seguridad de Web3, pero no elimina la responsabilidad del diseño y las operaciones. ZK-SNARK y otros sistemas ZK-Proof permiten fijar reglas de forma rígida y reducen el espacio para acciones arbitrarias de los operadores, pero al mismo tiempo crean una nueva capa de infraestructura crítica en la que cada error de diseño, implementación u operación se convierte inmediatamente en parte de la superficie de ataque. Un protocolo sólo se beneficia realmente de estos sistemas si el equipo crea un ciclo de vida completo de desarrollo, pruebas, auditoría y gestión de riesgos en torno a ellos.

No hace falta ser ingeniero para comprender los componentes clave de los proyectos criptográficos, evaluarlos exhaustivamente y darse cuenta de su verdadero potencial, capacidades y riesgos. Obtenga la Lista de Verificación de Cripto de DYOR: Evalúe los criptoproyectos antes de invertir

Conclusión

Zero-Knowledge Proofs, y más específicamente ZK-SNARK en combinación con otros sistemas ZK-Proof, se convierten en última instancia en la base que soporta la privacidad en Web3, variantes reales de escalado de Ethereum, y una parte significativa de la seguridad de Web3. No basta con que esta tecnología esté presente: lo que importa es cómo la utiliza el protocolo para fijar reglas de manejo de datos y estado, qué clases de declaraciones empuja a la capa criptográfica y cuáles deja todavía en la zona de acuerdos organizativos y confianza en la infraestructura.

En la práctica, un análisis sólido de cualquier red o protocolo que se base en Pruebas de Conocimiento Cero siempre se reduce a varias comprobaciones. En primer lugar, se analiza qué tipo específico de sistema ZK-Proof se ha elegido y qué compensaciones introduce en términos de tamaño de la prueba, costes de generación y verificación, dependencia de una configuración de confianza y el plan de actualización. A continuación, se examina el nivel real de privacidad que ofrece la pila: qué datos permanecen abiertos, cómo se organiza el control de acceso a los fragmentos privados, qué escenarios de divulgación ha formalizado el equipo y cuáles ha dejado a discreción de los operadores. Otro nivel de análisis se refiere a la seguridad de Web3: la transparencia con la que el proyecto fija invariantes en los circuitos, cómo estructura el proceso de verificación de la implementación y quién en el ecosistema es capaz de volver a comprobar estas decisiones de forma independiente.

Así pues, no se deduce que la tecnología de conocimiento-cero convierta automáticamente una red en fiable o prometedora. Define una nueva clase de herramientas que refuerzan los protocolos bien diseñados y, al mismo tiempo, castigan rápidamente las soluciones superficiales. Si un equipo explica claramente qué papel desempeñan las Pruebas de Conocimiento Cero y ZK-SNARK en la arquitectura, qué limitaciones introducen y qué riesgos se están controlando, estamos ante una pila con la que merece la pena seguir trabajando; si la tecnología aparece sólo como una afirmación genérica sin una conexión clara con la privacidad, el escalado y la seguridad, es una señal para ser especialmente cauteloso.

Stack 10% More on Your First BTCC Deposit

Start Trading

Preguntas más frecuentes

¿Qué es una ZK-SNARK en criptografía?

Un ZK-SNARK en criptografía es un esquema de prueba de conocimiento cero que permite demostrar la corrección de un cálculo sin revelar los datos de entrada. Es importante porque puede proporcionar una prueba muy compacta que la red verifica mucho más rápido que el propio cálculo original.

¿Cómo funcionan los ZK-SNARK?

El desarrollador describe la lógica como un circuito aritmético o un sistema de restricciones y ejecuta una configuración que crea los parámetros públicos. El prover toma las entradas públicas y el testigo privado y los utiliza para construir una prueba de que se cumplen todas las restricciones. El verificador sólo utiliza las entradas públicas, la prueba y los parámetros para comprobar la corrección sin conocer los datos privados.

¿Qué significa ZK-SNARK?

ZK-SNARK son las siglas de Zero-Knowledge Succinct Non-interactive Argument of Knowledge. Zero-Knowledge significa que la prueba no revela los datos secretos, Succinct que la prueba es corta y puede ser verificada rápidamente, Non-interactive que un solo mensaje del prover al verificador es suficiente, Argument of Knowledge que sin conocimiento real del testigo, es casi imposible generar una prueba válida.

¿Cómo se utilizan los ZK-SNARK en Ethereum?

En el ecosistema Ethereum, los ZK-SNARK se utilizan principalmente en zk-rollups y zkEVM, donde prueban la corrección de grandes lotes de transacciones L2 a un contrato L1. Además, se aplican en protocolos individuales para transferencias privadas, verificación en cadena de cálculos fuera de cadena y para pruebas de estado en puentes y sistemas de identidad.

¿Cuál es la diferencia entre ZK-SNARK y ZK-STARK?

Un ZK-SNARK se basa normalmente en emparejamientos sobre curvas elípticas, requiere una configuración de confianza y proporciona pruebas muy pequeñas con una verificación barata, pero se basa en suposiciones más complejas. Un ZK-STARK se construye sobre primitivas basadas en hash, no requiere una configuración de confianza y parece mejor a largo plazo y en un contexto post-cuántico, pero sus pruebas son más grandes y requieren más ancho de banda.

¿Los ZK-SNARK se utilizan para la privacidad o para el escalado?

Se utilizan tanto para la privacidad como para el escalado. En los protocolos privados, un ZK-SNARK oculta los valores y las relaciones entre los participantes, y la red sólo ve la corrección de las reglas. En soluciones de escalado, permite ejecutar transacciones fuera de la L1, empaquetarlas en lotes y confirmarlas con una única prueba, lo que reduce la carga de la red base.

¿Qué Blockchains utilizan la tecnología ZK-SNARK?

ZK-SNARK es el núcleo de las L1 privadas en la familia de diseños que siguen el modelo Zcash. Filecoin la utiliza ampliamente para las pruebas de almacenamiento de datos. En Ethereum, muchos zk-rollups y zkEVMs se basan en ZK-SNARK para probar sus estados, y también hay nuevos L1s que inicialmente diseñan su estado y transacciones en torno a este esquema.

¿Son anónimas las transacciones ZK-SNARK?

Pueden ocultar importes, direcciones de destinatarios y estructura de propiedad, pero el anonimato depende totalmente del diseño del protocolo y del comportamiento del usuario. Los metadatos de la red, los patrones de uso y los campos adicionales de las transacciones pueden desanonimizar a un usuario aunque la prueba en sí no revele el gráfico de la transferencia.

¿Por qué son importantes los ZK-SNARK para Web3?

Un ZK-SNARK permite preservar la verificabilidad criptográfica a la vez que se reduce el volumen de datos y cálculos públicos en la cadena. Como resultado, los protocolos Web3 pueden implementar activos e identidad privados, trasladar los cálculos pesados fuera de la cadena y seguir confirmando el resultado en una capa compartida en lugar de en un servicio de confianza independiente.

¿Es segura la tecnología de conocimiento-cero?

La teoría básica del conocimiento-cero y los modernos sistemas ZK-Proof se consideran criptográficamente robustos si se cumplen los supuestos. Los riesgos reales residen en la configuración de confianza, en el diseño de los circuitos, en la implementación y en los procesos de actualización, por lo que la seguridad de estos sistemas depende de la calidad de la ingeniería, las pruebas y la auditoría con la misma rigidez que la seguridad del consenso y la máquina virtual.