Trusted Setup

¿Qué es un trusted setup?

Un trusted setup es un proceso criptográfico utilizado para generar parámetros públicos para determinados sistemas de pruebas de conocimiento cero, esquemas de compromisos polinómicos y protocolos blockchain centrados en la privacidad.

En cripto, un trusted setup se trata con mayor frecuencia en relación con zk-SNARKs, compromisos KZG, monedas de privacidad, rollups y sistemas de datos blockchain escalables.

La configuración crea una cadena de referencia común, también denominada CRS, cadena de referencia estructurada o SRS, que los probadores y verificadores utilizan posteriormente para crear y comprobar pruebas.

La palabra «trusted» no significa que los usuarios deban confiar ciegamente en una empresa o un desarrollador.

Significa que la seguridad del sistema depende de que al menos un participante de la configuración genere honestamente aleatoriedad secreta y destruya después esa aleatoriedad secreta de forma permanente.

Si todos los participantes son deshonestos o están comprometidos, la configuración puede volverse insegura.

Si al menos un participante aporta aleatoriedad real y la elimina correctamente, los parámetros públicos finales pueden seguir siendo seguros.

La documentación de Ethereum sobre pruebas de conocimiento cero explica que la generación de parámetros públicos es sensible porque, si la entropía utilizada para generar el CRS llega a un probador deshonesto, este podría ser capaz de calcular pruebas falsas.

Para los usuarios de criptomonedas, el trusted setup es importante porque constituye una de las hipótesis de confianza ocultas detrás de algunos sistemas criptográficos avanzados.

Un protocolo puede estar descentralizado en la capa de transacciones y seguir dependiendo de una ceremonia de configuración que debe realizarse correctamente.

Por qué el trusted setup es importante en cripto

El trusted setup es importante porque muchos sistemas blockchain utilizan pruebas criptográficas para hacer que las transacciones sean privadas, escalables o más baratas de verificar.

Las pruebas de conocimiento cero pueden permitir a un usuario demostrar que una afirmación es verdadera sin revelar los datos privados que la sustentan.

Esto resulta útil para pagos privados, pruebas de identidad, pruebas de validez de rollups, sistemas que preservan el cumplimiento normativo y diseños de prueba de reservas.

Algunos de los sistemas de pruebas más eficientes requieren parámetros de configuración antes de poder utilizarse.

Si esos parámetros se generan de forma segura, el sistema puede producir pruebas pequeñas y rápidas.

Si esos parámetros se generan de forma insegura, los atacantes podrían crear pruebas falsas que parezcan válidas.

Esto puede amenazar la solidez de un protocolo.

La solidez significa que el verificador no debe aceptar como verdadera una afirmación falsa.

En una criptomoneda, una pérdida de solidez puede ser extremadamente grave porque podría permitir inflación oculta, retiradas no válidas, creación falsa de activos o transiciones de estado fraudulentas.

Por ello, el trusted setup no es solo un detalle técnico.

Es una hipótesis de seguridad que los usuarios, desarrolladores, auditores e inversores deben comprender antes de confiar en un protocolo criptográfico.

Cómo funciona un trusted setup

Un trusted setup suele comenzar cuando el equipo de un protocolo define el sistema criptográfico que necesita parámetros públicos.

Después, el equipo organiza una ceremonia en la que los participantes aportan aleatoriedad.

Cada participante recibe una entrada del paso anterior, añade su propia aleatoriedad secreta, produce una nueva salida y publica pruebas de que el paso se ha realizado correctamente.

Después, el participante debe destruir la aleatoriedad secreta que utilizó.

Esta aleatoriedad secreta se denomina en ocasiones toxic waste.

La salida pública final se convierte en el CRS o SRS utilizado por el sistema de pruebas.

El proceso suele diseñarse para que no sea necesario confiar plenamente en un único participante.

Siempre que un participante haya sido honesto y haya destruido su secreto, los parámetros finales deberían ser seguros conforme a las hipótesis de esa ceremonia.

Muchas ceremonias también publican transcripciones, herramientas de verificación, firmas y registros de contribuciones para que el público pueda comprobar que el proceso siguió las reglas.

Esta transparencia es importante porque un trusted setup no trata únicamente de criptografía.

También trata de la confianza pública en cómo se creó el material criptográfico.

¿Qué es el toxic waste?

El toxic waste es la información secreta generada durante una ceremonia de trusted setup que nunca debe revelarse ni reutilizarse.

El nombre es llamativo porque el secreto puede ser peligroso si perdura.

Si un atacante obtiene el toxic waste, podría ser capaz de falsificar pruebas, simular validez o quebrantar la seguridad del sistema que depende de la configuración.

Para un sistema zk-SNARK, el toxic waste puede permitir a un probador deshonesto crear pruebas de afirmaciones que no son realmente verdaderas.

Para una criptomoneda que se basa en tales pruebas, esto puede convertirse en un riesgo importante.

En algunos sistemas históricos de privacidad, el mayor temor era que el toxic waste pudiera permitir la creación no detectada de monedas o transacciones blindadas no válidas.

Por ello, los participantes de las configuraciones suelen aplicar una seguridad operativa sólida.

Pueden utilizar equipos aislados de redes, sistemas operativos live, entropía de fuentes físicas, destrucción de hardware o certificaciones públicas.

El proceso exacto depende del diseño de la ceremonia.

El principio básico es sencillo: los parámetros públicos deben permanecer, pero los secretos privados de la configuración deben desaparecer para siempre.

¿Qué es una ceremonia de computación multipartita?

Una ceremonia de computación multipartita, o ceremonia MPC, es un método de trusted setup que implica a numerosos participantes independientes.

En lugar de confiar en que una sola persona genere los parámetros honestamente, el sistema permite que muchas personas aporten aleatoriedad.

Cada participante añade entropía a la configuración.

Si tan solo un participante es honesto y destruye su secreto, la configuración final puede seguir siendo segura.

Esto se conoce en ocasiones como la hipótesis de «un participante honesto».

Las ceremonias MPC se popularizaron porque reducen la dependencia de una única parte de confianza.

También hacen que el proceso sea más público y esté más impulsado por la comunidad.

Una gran ceremonia puede incluir desarrolladores, investigadores, validadores, usuarios, auditores y miembros de la comunidad.

Sin embargo, más participantes no implican automáticamente una seguridad perfecta.

La ceremonia sigue necesitando software correcto, verificación clara, aleatoriedad sólida, publicación fiable de la transcripción y una protección cuidadosa frente a contribuciones maliciosas.

Una buena ceremonia MPC es tanto criptográficamente sólida como operativamente transparente.

Trusted setup y zk-SNARKs

zk-SNARK significa argumento sucinto no interactivo de conocimiento de cero conocimiento.

Los zk-SNARKs son populares en cripto porque pueden producir pruebas compactas que se verifican rápidamente.

Esto los hace útiles para sistemas de privacidad y escalabilidad.

Algunas construcciones zk-SNARK requieren un trusted setup.

La configuración genera parámetros públicos que posteriormente utilizan los probadores y verificadores.

Si la configuración es segura, el sistema de pruebas puede proporcionar sólidas garantías de privacidad y validez.

Si la configuración está comprometida, el sistema de pruebas puede aceptar pruebas falsas.

Este riesgo explica por qué las ceremonias de trusted setup se convirtieron en uno de los temas más debatidos en los primeros sistemas cripto de conocimiento cero.

La criptografía moderna ha introducido alternativas que reducen o eliminan los requisitos de trusted setup.

Sin embargo, los zk-SNARKs basados en trusted setup siguen siendo importantes porque pueden ser eficientes, compactos y prácticos para la verificación blockchain.

El equilibrio se sitúa entre eficiencia e hipótesis de confianza.

Trusted setup y compromisos KZG

Los compromisos KZG son un esquema de compromisos polinómicos utilizado en el sistema de transacciones blob de Ethereum y en otras aplicaciones criptográficas.

KZG corresponde a Kate, Zaverucha y Goldberg, los autores del esquema de compromisos.

Un compromiso KZG permite a un protocolo comprometerse con un polinomio y demostrar posteriormente afirmaciones sobre dicho polinomio de manera eficiente.

En Ethereum, los compromisos KZG se utilizan en el sistema de blobs introducido por EIP-4844, también llamado proto-danksharding.

La documentación oficial de Ethereum sobre danksharding explica que proto-danksharding permite a los rollups añadir datos más baratos a los bloques de Ethereum mediante blobs.

La misma documentación explica que la ceremonia KZG generó valores aleatorios utilizados para verificar los compromisos de datos blob.

Los compromisos KZG requieren un trusted setup porque la cadena de referencia estructurada incluye potencias secretas de un valor aleatorio que no deben conocerse.

Si se conociera el secreto de la configuración, un actor malicioso podría crear potencialmente compromisos o pruebas engañosos.

Por ello, Ethereum organizó una gran ceremonia pública KZG antes de utilizar compromisos KZG en producción.

Ceremonia KZG de Ethereum

La ceremonia KZG de Ethereum fue una gran ceremonia pública de trusted setup creada para los compromisos KZG utilizados por proto-danksharding.

La página oficial de Ethereum sobre la KZG Summoning Ceremony describe la ceremonia como un proceso para generar una cadena de referencia estructurada necesaria para los compromisos KZG.

Ethereum.org afirma que la ceremonia KZG tuvo más de 140.000 contribuciones, lo que la convirtió en la mayor ceremonia de este tipo del mundo.

El resumen de la KZG Ceremony de la Ethereum Foundation publicó el hash de la transcripción final y describió la salida final de la transcripción.

Esto importa porque el sistema de blobs de Ethereum depende de los compromisos KZG para verificar datos eficientemente.

Proto-danksharding entró en funcionamiento en Ethereum Mainnet con la actualización Cancun-Deneb, o Dencun, en marzo de 2024.

A fecha de 2026, la ceremonia KZG sigue siendo uno de los ejemplos reales más importantes de un trusted setup público a gran escala utilizado por un protocolo blockchain importante.

Para los usuarios, la ceremonia es en gran medida invisible.

Para la seguridad del protocolo, es una parte central del modelo de confianza detrás del sistema de compromisos blob de Ethereum.

Zcash y Powers of Tau

Zcash ayudó a que las ceremonias de trusted setup fueran ampliamente conocidas en la industria cripto.

La tecnología de privacidad inicial de Zcash se basaba en zk-SNARKs que requerían parámetros de configuración.

Posteriormente, el ecosistema de Zcash utilizó una ceremonia más amplia llamada Powers of Tau para crear parámetros públicos reutilizables para proyectos zk-SNARK.

El anuncio de la Zcash Foundation sobre Powers of Tau señaló que la ceremonia tenía como objetivo producir parámetros públicos parciales que pudieran utilizar proyectos basados en zk-SNARKs.

El mismo anuncio explicó que la corrección de las pruebas que utilizan esos parámetros requería que al menos un participante destruyera parte de la aleatoriedad generada durante la ceremonia.

Powers of Tau es importante porque trasladó el trusted setup de un pequeño evento privado hacia un proceso más abierto y con múltiples participantes.

También demostró que las ceremonias pueden publicar transcripciones y herramientas de verificación para que el público inspeccione los resultados.

El ejemplo de Zcash se utiliza a menudo para explicar por qué el trusted setup es potente, pero sensible.

Si la configuración funciona, los usuarios pueden beneficiarse de pruebas de privacidad eficientes.

Si la configuración se ve comprometida, los usuarios deben entender el riesgo para la solidez del sistema.

Trusted setup frente a configuración transparente

Un trusted setup exige que los participantes creen parámetros públicos mientras preservan y destruyen aleatoriedad secreta.

Una configuración transparente no requiere aleatoriedad oculta de participantes de confianza.

Los sistemas de pruebas transparentes utilizan aleatoriedad pública, funciones hash u otros métodos que evitan el toxic waste.

Los ZK-STARKs son un ejemplo habitual de sistema de pruebas transparente.

La documentación de Ethereum sobre pruebas de conocimiento cero explica que los ZK-STARKs se basan en aleatoriedad verificable públicamente en lugar de un trusted setup.

Esto hace que los ZK-STARKs sean más transparentes que los zk-SNARKs basados en trusted setup.

Sin embargo, los sistemas transparentes pueden tener contrapartidas.

Pueden producir pruebas más grandes o tener costes de verificación diferentes.

Los sistemas basados en trusted setup pueden ofrecer pruebas más pequeñas y una verificación más rápida en algunos casos de uso.

La elección depende de las necesidades del protocolo, el modelo de seguridad, el tamaño de la prueba, el coste del probador, el coste de verificación y las hipótesis de confianza de los usuarios.

Trusted setup universal frente a específico de un circuito

Un trusted setup específico de un circuito crea parámetros para un cálculo o circuito concreto.

Si el circuito cambia, puede ser necesario realizar de nuevo la configuración.

Esto puede resultar inconveniente para protocolos que necesitan actualizaciones frecuentes o muchos circuitos de pruebas distintos.

Un trusted setup universal crea parámetros que pueden admitir muchos circuitos hasta un determinado límite de tamaño o complejidad.

Las configuraciones universales son más flexibles porque varios proyectos o aplicaciones pueden reutilizar la misma salida de configuración.

Powers of Tau se analiza a menudo como una base de configuración universal o reutilizable para sistemas zk-SNARK.

Las configuraciones universales pueden reducir el número de ceremonias necesarias en un ecosistema.

Sin embargo, también pueden concentrar más valor en una única configuración.

Si muchos sistemas dependen de la misma configuración, la confianza en ella se vuelve más importante.

Los desarrolladores deben comprender si su sistema de pruebas utiliza una configuración específica de un circuito, universal, transparente o ninguna configuración.

Trusted setup y rollups

Los rollups son sistemas de escalabilidad blockchain que procesan transacciones off-chain y publican datos comprimidos o pruebas en una cadena base.

Algunos rollups utilizan pruebas de conocimiento cero para demostrar que las transiciones de estado son válidas.

Si el sistema de pruebas de un rollup se basa en un trusted setup, la seguridad de ese rollup también depende en parte de las hipótesis de configuración.

Esto no hace automáticamente que el rollup sea inseguro.

Significa que los usuarios deben comprender el modelo de confianza completo.

Un rollup puede depender de contratos inteligentes, secuenciadores, probadores, disponibilidad de datos, claves de actualización, gobernanza e hipótesis de configuración criptográfica.

El trusted setup es una parte de ese panorama de seguridad más amplio.

En el caso de los blobs de Ethereum, los compromisos KZG ayudan a que los datos de rollups sean más baratos de publicar y verificar.

La especificación EIP-4844 introdujo las transacciones portadoras de blobs, cuyos datos no pueden ser accedidos por la ejecución de la EVM, pero cuyo compromiso sí puede consultarse.

Esta es una razón importante por la que el trusted setup sigue siendo relevante para la escalabilidad moderna de Ethereum.

Trusted setup y monedas de privacidad

El trusted setup también ha sido importante en sistemas cripto centrados en la privacidad.

Las monedas de privacidad pueden utilizar pruebas de conocimiento cero para permitir a los usuarios demostrar que las transacciones son válidas sin revelar los datos del remitente, destinatario o importe.

Algunos sistemas de privacidad utilizaron históricamente zk-SNARKs basados en trusted setup porque las pruebas eran pequeñas y eficientes.

Esta eficiencia hizo que las transacciones privadas fueran más prácticas on-chain.

El riesgo era que una configuración comprometida pudiera afectar a la solidez.

En algunos sistemas, la privacidad en sí podría mantenerse protegida, pero la solidez monetaria podría verse amenazada si las pruebas falsas permitieran crear monedas no válidas.

Por ello, el diseño de la ceremonia de configuración fue una parte central de los primeros debates sobre la seguridad de las monedas de privacidad.

La investigación moderna sobre privacidad sigue explorando formas de mejorar los sistemas de pruebas, reducir las hipótesis de confianza y facilitar la verificación de los procesos de configuración.

Para los usuarios, el punto clave es que la tecnología de privacidad debe evaluarse tanto por sus garantías de privacidad como por las hipótesis de confianza de su sistema de pruebas.

Trusted setup y solidez

La solidez es la propiedad por la que una prueba falsa no debe verificarse como verdadera.

En cripto, la solidez es fundamental porque los contratos inteligentes y nodos blockchain pueden aceptar pruebas criptográficas automáticamente.

Si la solidez se rompe, el sistema puede aceptar retiradas no válidas, saldos falsos, transiciones de estado incorrectas o transacciones privadas falsificadas.

Un trusted setup puede afectar a la solidez porque los secretos de configuración pueden permitir la creación de pruebas falsas si se conocen.

Por ello debe destruirse el toxic waste.

Un verificador público normalmente no puede determinar si un trusted setup se vio comprometido simplemente observando pruebas posteriores.

Si los parámetros parecen válidos, pero un atacante conoce el secreto, este podría engañar de forma silenciosa.

Esto diferencia al trusted setup de muchos errores de software convencionales.

Un error normal puede corregirse después de descubrirse.

Una configuración comprometida puede requerir sustituir parámetros, migrar sistemas o cambiar el sistema de pruebas.

Trusted setup y conocimiento cero

El conocimiento cero es la propiedad por la que una prueba no revela información privada innecesaria más allá de la veracidad de la afirmación que se está demostrando.

El trusted setup se relaciona principalmente con la solidez, pero también puede formar parte del diseño más amplio del sistema de pruebas.

El anuncio de Powers of Tau de la Zcash Foundation indicó que el protocolo garantiza el conocimiento cero de las pruebas resultantes incluso si todos los participantes estuvieran comprometidos.

Esta distinción importa porque los sistemas de pruebas pueden tener propiedades de seguridad diferentes.

Una configuración comprometida podría afectar a la solidez sin exponer necesariamente la privacidad del usuario.

En otros sistemas, una implementación deficiente o una aleatoriedad inadecuada también podrían afectar a la privacidad.

Los usuarios deben evitar asumir que todos los fallos de configuración tienen las mismas consecuencias.

El riesgo exacto depende del sistema de pruebas, la aplicación y el diseño de la configuración.

Para traders e inversores, la cuestión práctica más importante es si una configuración comprometida podría generar daños económicos ocultos.

Para los usuarios de privacidad, la cuestión también es si podrían exponerse detalles de transacciones privadas.

Trusted setup y verificación pública

Un trusted setup se fortalece cuando el público puede verificar la transcripción de la ceremonia.

La verificación pública significa que cualquier persona puede comprobar que cada contribución siguió las reglas del protocolo.

Esto suele requerir publicar una transcripción, hashes, firmas, software, instrucciones y metadatos de las contribuciones.

La ceremonia KZG de Ethereum publicó un hash final de la transcripción y puso la transcripción a disposición para su verificación.

La Zcash Foundation también publicó parámetros, transcripciones, herramientas de verificación y certificaciones de participantes para Powers of Tau.

La verificación pública no demuestra que todos los participantes destruyeran su toxic waste.

Pero ayuda a demostrar que los pasos visibles de la ceremonia estaban bien formados.

La hipótesis del participante honesto sigue vigente.

Por esta razón, la transparencia de la ceremonia es necesaria, pero no siempre suficiente.

Una buena ceremonia necesita tanto salidas públicas verificables como una destrucción creíble de la entropía privada.

Trusted setup y tamaño de la ceremonia

Una ceremonia de mayor tamaño puede reducir la concentración de confianza porque más personas aportan aleatoriedad.

Si la ceremonia es segura siempre que un participante sea honesto, añadir más participantes independientes puede aumentar la confianza.

La ceremonia KZG de Ethereum es un ejemplo sólido porque involucró más de 140.000 contribuciones.

Sin embargo, el tamaño de la ceremonia no es el único factor relevante.

Si muchas contribuciones proceden de la misma entidad, la diversidad efectiva puede ser menor de lo que sugiere el número bruto.

Si el software de la ceremonia tiene un error, un gran número de participantes puede no resolver el problema.

Si resulta difícil verificar la transcripción, los usuarios pueden no ser capaces de comprobar el proceso de forma independiente.

Si el proceso de contribución se censura o es difícil de acceder, la ceremonia puede ser menos abierta de lo que parece.

Un buen análisis debe considerar el número y diversidad de participantes, la seguridad del software, la verificación de la transcripción, la calidad de la entropía y la gobernanza en torno a la configuración.

Trusted setup y auditorías de seguridad cripto

Las auditorías de seguridad de sistemas que utilizan trusted setup deben revisar más que el código de los contratos inteligentes.

Los auditores deben comprobar el sistema de pruebas, los parámetros de configuración, las claves de verificación, las bibliotecas de implementación, la transcripción de la ceremonia y la lógica de integración.

Un contrato inteligente puede llamar correctamente a un verificador, pero el verificador puede basarse en parámetros inseguros.

Un sistema de pruebas puede ser sólido en teoría, pero la implementación puede gestionar incorrectamente las entradas o los casos límite.

Una ceremonia puede ser válida, pero el proyecto puede utilizar la clave de verificación equivocada.

Un rollup puede utilizar un trusted setup de forma segura, pero la gobernanza puede permitir una actualización futura que sustituya el verificador por código inseguro.

Por ello, el análisis del trusted setup debe formar parte de una revisión completa de riesgos del protocolo.

Los usuarios deben buscar documentación clara que explique qué configuración se utilizó, si era universal o específica de un circuito, quién participó y cómo pueden verificarse los parámetros.

Los proyectos que no pueden explicar claramente sus hipótesis de configuración merecen una cautela adicional.

Trusted setup y actualizabilidad

La actualizabilidad puede interactuar con el riesgo de trusted setup.

Si un protocolo actualiza sus circuitos, contratos verificadores o sistema de pruebas, puede necesitar una nueva configuración o nuevos parámetros de verificación.

Una configuración específica de un circuito puede dejar de ser válida después de un cambio en el circuito.

Una configuración universal puede admitir nuevos circuitos sin una ceremonia completamente nueva, según el sistema de pruebas y los límites de tamaño.

Si un protocolo cambia silenciosamente los parámetros de prueba, los usuarios pueden no darse cuenta de que el modelo de confianza ha cambiado.

Por ello, las actualizaciones deben ser transparentes e idealmente estar protegidas por gobernanza, auditorías, timelocks y anuncios públicos.

En los rollups, las actualizaciones de verificadores pueden ser especialmente importantes porque controlan qué pruebas de transición de estado se aceptan.

En los sistemas de privacidad, las actualizaciones de parámetros pueden afectar tanto a las hipótesis de seguridad como a la confianza de los usuarios.

El trusted setup no debe tratarse como un evento de marketing puntual.

Debe formar parte del mantenimiento continuo del protocolo y de la divulgación pública de riesgos.

Trusted setup y cadena de referencia común

Una cadena de referencia común, o CRS, es el dato público compartido utilizado por probadores y verificadores en determinados sistemas de pruebas.

El CRS puede incluir elementos de grupo, potencias de un valor secreto u otro material criptográfico estructurado.

Los usuarios normalmente no interactúan con el CRS directamente.

Los desarrolladores y clientes de protocolo lo utilizan mediante software de generación y verificación de pruebas.

Si el CRS se generó mediante un trusted setup, el sistema depende de la hipótesis de que el secreto usado para construirlo es desconocido.

En algunos contextos, las personas utilizan CRS y SRS casi indistintamente.

SRS suele destacar que la cadena de referencia tiene estructura, como potencias de un valor oculto.

La cuestión clave es si la cadena de referencia se generó de forma transparente o mediante un trusted setup.

Comprenderlo ayuda a los usuarios a identificar dónde interviene la confianza en un sistema de conocimiento cero o de compromisos polinómicos.

Trusted setup y cadena de referencia estructurada

Una cadena de referencia estructurada, o SRS, es un conjunto de parámetros públicos con estructura matemática.

En los compromisos KZG, la SRS contiene valores relacionados con potencias secretas de un número aleatorio oculto.

Estos valores pueden utilizarse públicamente sin revelar el secreto.

Si el secreto se destruye y no puede reconstruirse, el sistema puede seguir siendo seguro.

Si el secreto se conoce, el sistema puede verse comprometido.

Por ello, los compromisos KZG requieren una ceremonia de trusted setup.

La SRS es potente porque permite compromisos y pruebas eficientes.

También es sensible porque la estructura oculta crea una hipótesis de confianza.

Para los desarrolladores, la gestión de la SRS incluye carga correcta, control de versiones, verificación y compatibilidad con el software de cliente.

Para los usuarios, la principal preocupación es si la SRS se generó y gestionó de forma segura.

Ventajas del trusted setup

La primera ventaja del trusted setup es la eficiencia.

Algunos sistemas de pruebas basados en trusted setup producen pruebas muy pequeñas y baratas de verificar on-chain.

La segunda ventaja es la escalabilidad práctica.

Las pruebas pequeñas son útiles cuando las blockchains necesitan verificar muchas transacciones o grandes cálculos off-chain.

La tercera ventaja son las herramientas maduras.

Muchos sistemas basados en trusted setup se han estudiado, implementado, auditado y utilizado en producción.

La cuarta ventaja es la compatibilidad con determinados esquemas de compromisos.

Los compromisos KZG son eficientes y útiles para la disponibilidad de datos y los sistemas de pruebas polinómicas, pero necesitan una SRS.

La quinta ventaja es la reutilización en el ecosistema.

Las configuraciones universales pueden admitir muchas aplicaciones sin requerir una nueva ceremonia cada vez.

Estas ventajas explican por qué el trusted setup sigue siendo relevante aunque existan sistemas de pruebas transparentes.

Riesgos del trusted setup

El mayor riesgo de un trusted setup es la exposición del toxic waste.

Si se conoce el secreto de configuración, los atacantes podrían ser capaces de falsificar pruebas o compromisos.

Otro riesgo es una diversidad deficiente de participantes.

Si todos los participantes están controlados o comprometidos por un atacante, falla la hipótesis del participante honesto.

Un tercer riesgo es un software de ceremonia defectuoso.

Si la herramienta de configuración es incorrecta, la ceremonia puede producir parámetros débiles o no válidos.

Un cuarto riesgo es una verificación insuficiente.

Si los usuarios no pueden verificar la transcripción, deben depender más de los organizadores.

Un quinto riesgo es una documentación poco clara.

Si un proyecto no explica su configuración claramente, los usuarios pueden no entender en qué están confiando.

Un sexto riesgo es la migración futura.

Si posteriormente un trusted setup se considera inseguro, el protocolo puede necesitar migrar a nuevos parámetros o a un nuevo sistema de pruebas.

Trusted setup frente a ausencia de trusted setup

Un sistema con trusted setup puede ser muy eficiente, pero requiere confianza en la ceremonia.

Un sistema sin trusted setup puede reducir la confianza relacionada con la ceremonia, pero puede tener contrapartidas de rendimiento diferentes.

Los ZK-STARKs se utilizan a menudo como ejemplo de un sistema de pruebas transparente que evita el trusted setup.

Algunos sistemas SNARK modernos también pretenden reducir, universalizar o eliminar las hipótesis de configuración.

La mejor elección depende de lo que necesite el protocolo.

Un sistema de pagos privados puede priorizar pruebas pequeñas y un bajo coste de verificación.

Un rollup puede priorizar el rendimiento del probador, el coste de verificación y la flexibilidad de actualización.

Un sistema de disponibilidad de datos puede priorizar compromisos eficientes y compatibilidad con el muestreo.

Un sistema que gestiona un valor extremadamente elevado puede preferir menos hipótesis de confianza, aunque las pruebas sean mayores.

No existe una respuesta única para todos los casos.

El trusted setup es un equilibrio de diseño que debe evaluarse en su contexto.

Cómo pueden evaluar los usuarios un trusted setup

Los usuarios deben preguntar primero si el protocolo utiliza un trusted setup.

Después, deben preguntar qué sistema de pruebas o esquema de compromisos depende de esa configuración.

Deben comprobar si la configuración era universal o específica de un circuito.

Deben comprobar si existe una transcripción pública.

Deben comprobar si hay herramientas de verificación independientes disponibles.

Deben comprobar cuántos participantes contribuyeron y si la participación fue abierta.

Deben comprobar si el proyecto explica claramente sus hipótesis sobre el toxic waste.

Deben comprobar si el protocolo se ha auditado después de integrar los parámetros de configuración.

Deben comprobar si futuras actualizaciones pueden sustituir los parámetros de prueba sin controles de gobernanza sólidos.

Para depósitos grandes o uso a largo plazo, el trusted setup debe formar parte de la revisión de riesgos del usuario.

Trusted setup y riesgo de trading

El trusted setup puede afectar al riesgo de trading cuando un token, rollup, bridge o sistema de privacidad depende de la solidez de las pruebas.

Si una configuración cuenta con amplia confianza y está bien documentada, puede contribuir a la confianza en el protocolo.

Si una configuración es controvertida, opaca o está mal verificada, los traders pueden asignar un riesgo mayor al activo relacionado.

Un fallo de configuración puede no aparecer en los gráficos de precios antes de que el riesgo se vuelva grave.

Puede ser un riesgo técnico oculto, más que una señal de mercado visible.

Esto importa para los traders porque los mercados cripto suelen valorar las narrativas más rápido que los detalles técnicos.

Un protocolo puede parecer sólido por tener un TVL elevado, alto volumen o una marca fuerte.

Sin embargo, si su sistema de pruebas depende de hipótesis de configuración débiles, su riesgo real puede ser mayor de lo que percibe el mercado.

Por tanto, el riesgo técnico debe formar parte del análisis fundamental.

El trusted setup es especialmente importante cuando el protocolo protege grandes cantidades de fondos de usuarios.

Trusted setup y DeFi

Los protocolos DeFi pueden utilizar trusted setup indirectamente a través de rollups, capas de privacidad, sistemas de pruebas o herramientas de disponibilidad de datos.

Una aplicación DeFi desplegada en un rollup puede depender del sistema de pruebas de validez de ese rollup.

Si el sistema de pruebas del rollup utiliza trusted setup, la aplicación DeFi hereda indirectamente parte de esa hipótesis.

Un protocolo de préstamos que utiliza pruebas de identidad o cumplimiento de conocimiento cero también puede depender de parámetros de configuración.

Un protocolo de trading privado o de activos privados puede depender de sistemas de pruebas basados en trusted setup para ocultar datos sensibles mientras demuestra la validez.

Para los usuarios de DeFi, el trusted setup suele estar oculto bajo la interfaz de la aplicación.

La aplicación puede mostrar un sencillo botón de depósito, swap o préstamo.

Detrás de ese botón puede haber sistemas de pruebas, contratos verificadores, esquemas de compromisos, secuenciadores o hipótesis de disponibilidad de datos.

Comprender el trusted setup ayuda a los usuarios a ver que el riesgo de DeFi tiene varias capas.

Trusted setup y desarrolladores

Los desarrolladores deben tratar el trusted setup como infraestructura crítica para la seguridad.

Deben elegir sistemas de pruebas basándose en equilibrios claros y no en la publicidad.

Deben documentar si los parámetros de configuración son universales, específicos de un circuito, reutilizables o específicos de una aplicación.

Deben publicar instrucciones de verificación para usuarios y auditores.

Deben evitar cambiar silenciosamente claves de prueba, contratos verificadores o archivos CRS.

Deben utilizar bibliotecas auditadas cuando sea posible.

Deben probar que la generación y verificación de pruebas utilizan los mismos parámetros esperados.

Deben incluir las hipótesis de configuración en la documentación de seguridad y los modelos de amenazas.

Deben planificar qué sucede si los parámetros necesitan rotarse, sustituirse o dejar de utilizarse.

Un trusted setup no es solo una ceremonia criptográfica; también es una responsabilidad de mantenimiento a largo plazo.

Malentendidos habituales sobre el trusted setup

El primer malentendido es que trusted setup significa que el sistema está centralizado.

Un trusted setup puede involucrar a muchos contribuyentes independientes y seguir respaldando un protocolo descentralizado.

El segundo malentendido es que todos los trusted setups son igual de arriesgados.

El riesgo depende del diseño de la ceremonia, la diversidad de los participantes, la verificación de la transcripción, la calidad del software y las hipótesis del sistema de pruebas.

El tercer malentendido es que el trusted setup siempre amenaza la privacidad de los usuarios.

En muchos sistemas, el principal riesgo de configuración es la solidez de las pruebas, en lugar de una filtración directa de privacidad.

El cuarto malentendido es que una ceremonia grande elimina todo el riesgo.

Una ceremonia grande mejora la confianza solo si el software, la verificación, la entropía y el proceso de participación son sólidos.

El quinto malentendido es que los sistemas de pruebas transparentes siempre son mejores.

Los sistemas transparentes reducen la confianza en la configuración, pero pueden tener pruebas más grandes o perfiles de costes diferentes.

El sexto malentendido es que los usuarios nunca deben preocuparse por la configuración.

Los usuarios deben preocuparse cuando la configuración protege activos, validez de rollups, privacidad o lógica crítica del protocolo.

Lista de comprobación de trusted setup

Comprueba si el protocolo utiliza zk-SNARKs, compromisos KZG u otro sistema dependiente de configuración.

Comprueba si la configuración fue pública, privada, universal o específica de un circuito.

Comprueba si la ceremonia utilizó computación multipartita.

Comprueba si basta con que un participante sea honesto para garantizar la seguridad.

Comprueba si se explica claramente la destrucción del toxic waste.

Comprueba si la transcripción, el hash final y las herramientas de verificación son públicos.

Comprueba si los contratos verificadores y las claves de prueba están auditados.

Comprueba si las actualizaciones pueden sustituir los parámetros de prueba.

Comprueba si el protocolo tiene un plan para migrar desde parámetros antiguos si fuera necesario.

Comprueba si el proyecto explica las hipótesis de configuración en un lenguaje sencillo para los usuarios.

Preguntas frecuentes

¿Qué es un trusted setup en términos sencillos?

Un trusted setup es una ceremonia criptográfica que crea parámetros públicos para un sistema de pruebas y exige que se destruya la aleatoriedad secreta de los participantes.

¿Por qué se denomina trusted setup?

Se denomina trusted setup porque los usuarios deben confiar en que al menos un participante aportó aleatoriedad honesta y destruyó el toxic waste secreto.

¿Qué es el toxic waste en un trusted setup?

El toxic waste es la aleatoriedad secreta creada durante la configuración que podría ser peligrosa si perdura o se revela.

¿Por qué algunos zk-SNARKs necesitan trusted setup?

Algunos zk-SNARKs necesitan trusted setup porque sus parámetros públicos de generación y verificación de pruebas dependen de aleatoriedad secreta generada antes de utilizar el sistema.

¿Qué ocurre si un trusted setup se ve comprometido?

Si la configuración se ve comprometida, los atacantes podrían ser capaces de crear pruebas o compromisos falsos que parezcan válidos.

¿Un trusted setup siempre afecta a la privacidad?

No siempre, porque en muchos sistemas el principal riesgo es una pérdida de solidez, no una filtración directa de privacidad.

¿Qué es una ceremonia MPC?

Una ceremonia MPC es un proceso de configuración multipartita en el que muchos participantes aportan aleatoriedad, de modo que la configuración se mantiene segura si al menos un participante es honesto.

¿Qué fue la ceremonia KZG de Ethereum?

La ceremonia KZG de Ethereum fue una ceremonia pública de trusted setup que generó la cadena de referencia estructurada utilizada para los compromisos KZG del sistema de blobs de Ethereum.

¿Qué fue Powers of Tau?

Powers of Tau fue una gran ceremonia relacionada con Zcash diseñada para producir parámetros públicos reutilizables para sistemas zk-SNARK.

¿Los ZK-STARKs no requieren trusted setup?

Sí, los ZK-STARKs suelen describirse como sistemas de pruebas transparentes porque se basan en aleatoriedad verificable públicamente en lugar de un trusted setup.

¿El trusted setup es malo?

El trusted setup no es automáticamente malo, pero es una hipótesis de confianza que debe comprenderse, documentarse y verificarse.

¿Por qué los protocolos siguen utilizando sistemas con trusted setup?

Los protocolos pueden utilizar sistemas con trusted setup porque pueden ofrecer pruebas pequeñas, verificación eficiente, herramientas maduras y un rendimiento blockchain práctico.

¿Puede reutilizarse un trusted setup?

Algunos trusted setups universales pueden reutilizarse en muchos circuitos o aplicaciones, mientras que las configuraciones específicas de un circuito se limitan a un diseño de circuito.

¿Cómo pueden comprobar los usuarios la seguridad de un trusted setup?

Los usuarios pueden revisar la documentación de la ceremonia, el número de participantes, la disponibilidad de la transcripción, las herramientas de verificación, las auditorías y los controles de actualización.

Conclusión

Un trusted setup es un proceso criptográfico que genera parámetros públicos para determinados sistemas de pruebas y esquemas de compromisos utilizados en cripto.

Es especialmente importante para zk-SNARKs, compromisos KZG, sistemas de privacidad, rollups y diseños de datos blockchain escalables.

La idea principal de seguridad es que la aleatoriedad secreta creada durante la ceremonia debe destruirse.

Si al menos un participante actúa honestamente y elimina su toxic waste, la configuración puede mantenerse segura conforme a las hipótesis de la ceremonia.

Si todos los participantes son deshonestos o están comprometidos, el sistema puede volverse vulnerable a pruebas falsas o compromisos no válidos.

El trusted setup ha permitido sistemas criptográficos eficientes, incluidas pruebas pequeñas y verificación on-chain práctica.

También ha planteado importantes cuestiones de confianza y transparencia para los usuarios de blockchain.

Entre los principales ejemplos se incluyen las ceremonias Powers of Tau relacionadas con Zcash y la ceremonia KZG pública de Ethereum para proto-danksharding.

Los sistemas de pruebas transparentes modernos, como ZK-STARKs, reducen o eliminan las hipótesis de trusted setup, pero pueden implicar equilibrios de rendimiento diferentes.

La mejor forma de entender el trusted setup es tratarlo como una elección de diseño, no como un simple defecto.

Para los usuarios, el trusted setup debe formar parte del análisis de riesgos del protocolo.

Para los desarrolladores, debe formar parte de la arquitectura de seguridad, el alcance de auditoría, la documentación y la planificación de actualizaciones.

Para el ecosistema cripto en general, el trusted setup demuestra que la descentralización depende no solo del consenso y los contratos inteligentes, sino también de los fundamentos criptográficos que hacen posibles las aplicaciones blockchain avanzadas.