CRS (cadena de referencia común)

¿Qué es CRS (Common Reference String)?

CRS son las siglas de Common Reference String, un conjunto compartido de parámetros criptográficos públicos que utiliza un sistema de pruebas de conocimiento cero.En el ámbito de las criptomonedas, suele hablarse del CRS en relación con zk-SNARK, protocolos de privacidad, pruebas de validez, zk-rollups, compromisos polinómicos y sistemas de escalabilidad de blockchain.Un CRS proporciona una base común al prover y al verificador, de modo que se pueda generar y comprobar una prueba sin que el prover revele información privada.El prover utiliza el CRS para generar una prueba y el verificador emplea ese mismo CRS para comprobar si es válida.

La guía de ethereum.org sobre pruebas de conocimiento cero explica que los parámetros públicos utilizados en algunos sistemas de conocimiento cero se conocen colectivamente como Common Reference String.

Un CRS no es una contraseña, una clave privada, una frase de recuperación de una cartera ni un secreto de usuario.Normalmente es información pública, aunque el proceso utilizado para generarlo puede ser extremadamente delicado.Si el CRS se genera de forma honesta y se destruye el material secreto de configuración, el sistema de pruebas puede funcionar según lo previsto.Si el CRS se genera de forma deshonesta o se conserva el material secreto de configuración, algunos sistemas de pruebas pueden permitir la creación de pruebas falsas.Por eso, la seguridad del CRS es uno de los supuestos de confianza más importantes en muchos sistemas de conocimiento cero utilizados en el ámbito cripto.

Por qué es importante CRS en el ámbito cripto

CRS es importante porque las pruebas de conocimiento cero son ahora una tecnología fundamental para la privacidad, la escalabilidad y la identidad en blockchain, así como para la computación verificable.Una prueba de conocimiento cero permite demostrar que una afirmación es verdadera sin revelar los datos ocultos que la sustentan.En el ámbito cripto, esto puede consistir en demostrar que una transacción privada es válida, que un lote de transacciones off-chain se ha calculado correctamente o que un usuario cumple una regla sin revelar todos sus datos personales.Muchos sistemas zk-SNARK eficientes necesitan parámetros públicos antes de que se puedan generar y verificar pruebas.Esos parámetros públicos son el CRS o una estructura relacionada, como una Structured Reference String.

La explicación de ZKProof sobre las ceremonias de configuración indica que los zk-SNARK se basan en un CRS como parámetro público para generar y verificar pruebas.

Por eso, la calidad del CRS es importante tanto para desarrolladores como para usuarios.Los desarrolladores deben saber si el CRS es compatible con el circuito, el sistema de pruebas y el modelo de seguridad.Los usuarios deben saber si un protocolo depende de una configuración de confianza, una configuración universal, una ceremonia actualizable o un sistema de pruebas transparente que prescinde de una configuración de confianza.Para los inversores y traders de criptomonedas, CRS puede parecer un concepto técnico, pero puede influir en la credibilidad de las privacy coins, los zk-rollups, los bridges, los sistemas de pruebas y las aplicaciones tokenizadas.

Cómo funciona un CRS

Un CRS funciona proporcionando los mismos datos de referencia públicos a todos los participantes de un sistema de pruebas.El prover utiliza esos datos de referencia para convertir un testigo privado y una afirmación pública en una prueba compacta.El verificador utiliza los mismos datos para comprobar que la prueba se ha generado conforme a las reglas del sistema.La afirmación pública es lo que se intenta verificar.El testigo privado es la información oculta que hace que la afirmación sea verdadera.Por ejemplo, un usuario puede demostrar que una transacción cumple las reglas del protocolo sin revelar todos sus detalles privados.El CRS ayuda al sistema de pruebas a conectar la afirmación matemática, el testigo privado y el algoritmo de verificación.En muchos sistemas zk-SNARK, el CRS se crea antes de que los usuarios normales generen pruebas.Este paso de configuración puede ser específico de un circuito o lo bastante amplio como para admitir muchos circuitos.Los detalles dependen del sistema de pruebas, los supuestos criptográficos y el diseño de la implementación.El CRS debe generarse, almacenarse, publicarse y verificarse de forma que se reduzca la posibilidad de manipulación encubierta.

CRS, SRS y parámetros públicos

CRS suele utilizarse como término general para los datos de referencia públicos de un sistema de pruebas.SRS son las siglas de Structured Reference String, que normalmente se refiere a una cadena de referencia con una estructura algebraica especial.Parámetros públicos es una expresión más general que puede incluir CRS, SRS, claves de prueba, claves de verificación y otros resultados de la configuración.En conversaciones informales sobre criptomonedas, a veces se utilizan CRS y SRS como si significaran lo mismo.En textos más técnicos, SRS suele designar un tipo específico de CRS utilizado por ciertos SNARK o esquemas de compromisos polinómicos.

La guía de ZKDocs sobre compromisos polinómicos KZG describe los parámetros públicos pregenerados para los compromisos KZG y señala que a veces se denominan Structured Reference String.

La diferencia importa porque no todos los sistemas de pruebas utilizan el mismo tipo de material de configuración.Algunos sistemas necesitan un CRS específico para cada circuito.Otros utilizan una SRS universal que puede admitir muchos circuitos hasta un tamaño definido.Algunos sistemas son transparentes y no necesitan ninguna ceremonia de configuración de confianza.Un desarrollador prudente siempre debe comprobar qué quiere decir el proyecto con CRS, SRS, parámetros de configuración, clave de prueba y clave de verificación.

Configuración de confianza y CRS

Una configuración de confianza es un proceso utilizado para generar el CRS en algunos sistemas de pruebas de conocimiento cero.Se habla de confianza porque los participantes deben confiar en que la configuración se ha realizado correctamente y que se ha destruido cualquier aleatoriedad secreta.Este material secreto de configuración suele denominarse toxic waste.Si un atacante conserva el toxic waste, en algunos sistemas podría ser capaz de crear pruebas falsas.Esto no significa que todos los CRS sean inseguros.Significa que la seguridad de algunos sistemas basados en CRS depende de que el proceso de configuración sea seguro.Una sola parte puede realizar una configuración de confianza, pero eso plantea un grave problema de confianza.Los sistemas modernos suelen preferir ceremonias multipartitas porque reducen la dependencia de un único actor.En muchas ceremonias de configuración multipartitas, la seguridad se mantiene si al menos un participante honesto aporta aleatoriedad y destruye su contribución secreta.Por eso, las ceremonias públicas suelen intentar maximizar la participación, la transparencia, la reproducibilidad y la verificación independiente.Para los usuarios de criptomonedas, la pregunta principal no es solo si existe un CRS, sino también cómo se generó.

Ceremonia de computación multipartita

Una ceremonia de computación multipartita es un proceso de configuración en el que numerosos participantes independientes aportan aleatoriedad para crear el CRS.El objetivo es evitar que una sola persona, empresa, grupo de validadores o equipo de desarrollo controle todo el secreto de configuración.Cada participante añade entropía a la ceremonia y, después, destruye su contribución privada.En muchos diseños de ceremonias, el CRS final puede seguir siendo seguro si al menos un participante actúa de forma honesta.Este modelo se utiliza habitualmente cuando un sistema de pruebas necesita una configuración de confianza, pero la comunidad quiere reducir la confianza depositada en una sola parte.La ceremonia KZG de Ethereum es un conocido ejemplo cripto de una ceremonia pública utilizada para generar material de configuración para los compromisos KZG.

El resumen de la ceremonia KZG de la Ethereum Foundation la describe como un proceso público que contribuyó a la base criptográfica de EIP-4844.

Una ceremonia debe publicar información suficiente para que otras personas puedan auditar el proceso.Un buen diseño de ceremonia también protege frente a contribuciones maliciosas, aleatoriedad débil, software comprometido y riesgos de coordinación centralizada.Una ceremonia sólida no elimina todos los riesgos del sistema, pero puede reducir la carga de confianza asociada al CRS.

CRS y zk-SNARK

zk-SNARK son las siglas de Zero-Knowledge Succinct Non-Interactive Argument of Knowledge.Muchos sistemas zk-SNARK son rápidos de verificar y generan pruebas pequeñas, lo que los hace útiles en las blockchains.Las pruebas pequeñas son importantes porque el almacenamiento y la verificación en blockchain pueden resultar costosos.Las pruebas no interactivas son importantes porque el prover puede generar una prueba una sola vez y publicarla para que cualquiera la verifique más adelante.En muchas construcciones SNARK, el CRS contribuye a hacer posible este modelo no interactivo.Sin los parámetros de configuración adecuados, es posible que el prover y el verificador no compartan las referencias matemáticas necesarias para generar y validar la prueba.Las distintas familias SNARK gestionan de forma diferente los requisitos del CRS.Algunos sistemas antiguos requieren una configuración de confianza independiente para cada circuito.Algunos sistemas más recientes utilizan modelos de configuración universal o actualizable.Algunos sistemas de pruebas reducen o eliminan la necesidad de una configuración de confianza mediante otros diseños criptográficos.Por eso, un proyecto cripto no debería limitarse a decir que utiliza zk-SNARK.También debería explicar el modelo de configuración, el tipo de CRS, el proceso de auditoría y la vía de actualización.

CRS y zk-rollups

Un zk-rollup es un sistema de escalabilidad de blockchain que utiliza pruebas de validez para demostrar que los lotes de transacciones procesados off-chain se han ejecutado correctamente.

La documentación de ethereum.org sobre zk-rollups explica que un protocolo ZK-SNARK puede necesitar un CRS, ya que este proporciona parámetros públicos para generar y verificar pruebas de validez.

En un zk-rollup, un prover genera una prueba para muchas transacciones a la vez.La blockchain base verifica la prueba en lugar de volver a ejecutar todas las transacciones del lote.Esto puede reducir la cantidad de datos y cálculos necesarios en la capa base.Si el rollup utiliza un sistema de pruebas basado en CRS, el CRS forma parte de sus supuestos de confianza y de su modelo de seguridad.Los usuarios deben comprobar si el rollup utiliza una configuración de confianza, si esta era específica para un circuito y si las futuras actualizaciones requieren nuevas ceremonias.Un CRS defectuoso o comprometido podría debilitar el sistema de pruebas de validez.Un proceso de configuración sólido puede aportar confianza en que resulta difícil falsificar las pruebas del rollup.Por tanto, el diseño del CRS no es solo un tema académico, ya que puede afectar a los fondos reales de los usuarios en los sistemas de escalabilidad.

CRS y compromisos KZG

Los compromisos KZG son un tipo de esquema de compromisos polinómicos utilizado en la investigación y el desarrollo actuales sobre escalabilidad de blockchain.Un compromiso polinómico permite a una parte comprometerse con un polinomio y demostrar posteriormente afirmaciones sobre sus valores sin revelar el polinomio completo.Esto resulta útil para la disponibilidad de datos, la escalabilidad de los rollups y los sistemas de pruebas, ya que permite verificar de forma compacta grandes estructuras de datos.EIP-4844 introdujo transacciones con blobs que utilizan compromisos y pruebas KZG como parte de la hoja de ruta de escalabilidad de Ethereum.

La especificación EIP-4844 describe las transacciones con blobs y la verificación de pruebas KZG en el diseño del protocolo.

Los compromisos KZG dependen de material de configuración estructurado.Este material suele denominarse SRS, que puede entenderse como una forma especializada de CRS.La seguridad de los sistemas basados en KZG depende de que se destruya durante la configuración la aleatoriedad secreta correspondiente.Por eso, las ceremonias KZG reciben tanta atención en la ingeniería cripto.Una SRS KZG no es un simple archivo técnico, ya que puede constituir una dependencia criptográfica a largo plazo para las aplicaciones que la utilizan.

CRS universal y CRS específico para un circuito

Un CRS específico para un circuito se genera para un circuito o cálculo concreto.Si el circuito cambia, el proyecto puede necesitar una nueva configuración.Esto puede resultar incómodo porque las aplicaciones blockchain suelen actualizarse con el tiempo.Un CRS universal o una SRS universal puede admitir muchos circuitos hasta un límite determinado de tamaño o complejidad.Esto puede facilitar el desarrollo, ya que muchas aplicaciones pueden reutilizar el mismo material de configuración.Un CRS actualizable permite que nuevos participantes añadan aleatoriedad después de la configuración inicial.Esto puede aumentar la confianza porque la configuración puede seguir recibiendo nuevas contribuciones con el tiempo.Los diseños universales y actualizables cobraron importancia porque reducen la carga operativa de repetir ceremonias de configuración de confianza.Sin embargo, universal no significa ilimitado.Un CRS universal suele tener límites, supuestos, curvas compatibles, tamaños máximos de circuito y reglas de implementación.Los desarrolladores deben comprobar si el CRS es adecuado para la aplicación que están creando.

Sistemas de pruebas transparentes y CRS

Un sistema de pruebas transparente no requiere una ceremonia de configuración de confianza.En su lugar, puede utilizar aleatoriedad pública, funciones hash u otras construcciones que evitan el material secreto de configuración.Los zk-STARK suelen describirse como transparentes porque no requieren un CRS de configuración de confianza del mismo modo que muchos zk-SNARK.Esta es una de las razones por las que los sistemas basados en STARK resultan atractivos para algunas aplicaciones blockchain.La contrapartida es que los sistemas transparentes pueden tener tamaños de prueba, costes de verificación, costes de generación de pruebas o requisitos de implementación distintos.Un sistema sin configuración de confianza no es automáticamente mejor para todos los casos de uso.Un SNARK basado en CRS puede ofrecer pruebas más pequeñas y una verificación eficiente.Un sistema de pruebas transparente puede reducir la confianza en la configuración, aunque implique otras contrapartidas de rendimiento.Un buen diseño de protocolo compara los supuestos de seguridad, el coste, el rendimiento, las herramientas para desarrolladores, la calidad de las auditorías y la facilidad de mantenimiento a largo plazo.Para los usuarios, la idea fundamental es sencilla: algunos sistemas ZK necesitan un CRS y otros están diseñados para evitar un CRS de confianza.

Riesgos de seguridad del CRS

El mayor riesgo relacionado con el CRS es que la configuración se vea comprometida.Si no se destruye el material secreto de configuración, en algunos sistemas de pruebas un atacante podría falsificar pruebas.El riesgo de falsificación puede ser grave porque una blockchain podría aceptar como válida una prueba falsa.En un sistema de pagos, esto podría poner en peligro las reglas de los saldos privados o la validez de las transacciones protegidas.En un rollup, podría amenazar la corrección de las transiciones de estado off-chain.En un bridge, podría poner en peligro las afirmaciones sobre depósitos, retiradas o estados entre cadenas.Otro riesgo consiste en utilizar un CRS incorrecto para un circuito o sistema de pruebas determinado.Una incompatibilidad entre el CRS, el circuito, la clave de prueba, la clave de verificación y la implementación puede vulnerar la seguridad o impedir que las pruebas se verifiquen.Un tercer riesgo es la falta de transparencia de la ceremonia.Si los usuarios no pueden verificar cómo se generó el CRS, deben confiar en las afirmaciones del equipo del proyecto.Un cuarto riesgo es una higiene deficiente del software durante la configuración.El malware, una aleatoriedad defectuosa, puertas traseras ocultas o procesos de compilación inseguros pueden dañar la ceremonia.Por tanto, la seguridad del CRS es un problema tanto criptográfico como de seguridad operativa.

Cómo utilizan los desarrolladores un CRS

Los desarrolladores utilizan un CRS al crear aplicaciones que dependen de la generación y verificación de pruebas.El CRS puede descargarse de una publicación de confianza, generarse mediante una ceremonia, integrarse en el software o referenciarse en la especificación de un protocolo.El software del prover utiliza el material de configuración para generar pruebas válidas para un circuito.El software del verificador utiliza el material de verificación relacionado para comprobar las pruebas de forma eficiente.En los sistemas de contratos inteligentes, la clave de verificación puede incorporarse a un contrato verificador on-chain.Esto permite que la blockchain compruebe la validez de la prueba sin conocer el testigo privado.Los desarrolladores deben asegurarse de que el CRS procede de la ceremonia correcta y coincide con la versión exacta del sistema de pruebas.También deben comprobar los hashes, las firmas, las compilaciones reproducibles, la documentación oficial y los informes de auditoría.Una pequeña incompatibilidad en la configuración puede provocar errores de verificación, gasto inútil de gas, aplicaciones defectuosas o una seguridad más débil.Por eso, los sistemas ZK de producción consideran que los archivos de configuración son infraestructura crítica.

CRS y privacy coins

Históricamente, el CRS ha sido importante para los sistemas de criptomonedas centrados en la privacidad que utilizaban zk-SNARK.Los protocolos de privacidad pueden utilizar pruebas de conocimiento cero para demostrar la validez de transacciones protegidas sin revelar información sensible sobre ellas.Los primeros diseños eficientes de zk-SNARK solían depender de ceremonias de configuración de confianza.Zcash es uno de los ejemplos más conocidos de un proyecto de criptomoneda que convirtió la configuración de confianza y su posterior eliminación en un tema importante de investigación.

La explicación de Zcash sobre los zk-SNARK señala que Zcash introdujo el protocolo de pagos protegidos Orchard con Halo 2 y explica que Halo elimina la configuración de confianza y permite realizar pagos digitales privados.

Esta evolución muestra que el diseño del CRS cambia con el tiempo.Los primeros sistemas pueden aceptar una configuración de confianza para conseguir pruebas pequeñas y un rendimiento práctico.Los sistemas posteriores pueden avanzar hacia diseños de pruebas que reduzcan la confianza en la configuración o la eliminen de partes fundamentales del protocolo.La lección importante para los usuarios es que las afirmaciones sobre privacidad deben evaluarse teniendo en cuenta también los supuestos de configuración.Un protocolo de privacidad sólido debe explicar tanto qué oculta como qué supuestos de confianza requiere.

CRS y actualizaciones de blockchain

Las actualizaciones de blockchain pueden plantear dificultades relacionadas con el CRS, porque los nuevos circuitos o sistemas de pruebas pueden necesitar nuevo material de configuración.Si un protocolo cambia sus reglas de transacción, su diseño de escalabilidad o su sistema de pruebas, es posible que el CRS anterior ya no sea suficiente.Una configuración específica para un circuito puede requerir una nueva ceremonia para una actualización importante.Una configuración universal puede ofrecer más flexibilidad, pero también tiene límites.Los equipos de protocolo deben planificar cómo se proponen, auditan, ejecutan, publican y activan los cambios de configuración.La gobernanza también importa, ya que los usuarios deben confiar en que una actualización no introduzca de forma encubierta supuestos de prueba más débiles.Un buen proceso de actualización debe documentar la configuración anterior y la nueva, los riesgos de migración y los cambios de verificación.En los sistemas descentralizados, la revisión de la comunidad es importante porque los cambios del CRS pueden afectar a todos los usuarios que dependen de la validez de las pruebas.Esto es especialmente cierto en los sistemas que protegen depósitos, retiradas, saldos privados o raíces de estado de rollups.Por tanto, la gobernanza del CRS forma parte de la seguridad cripto a largo plazo.

Cómo evaluar un proyecto cripto basado en CRS

La primera pregunta es si el proyecto utiliza un sistema de pruebas basado en CRS.La segunda es si el CRS lo generó una sola parte o se creó mediante una ceremonia pública multipartita.La tercera es si la configuración es específica para un circuito, universal o actualizable.La cuarta es si son públicos el registro de la ceremonia, el software, los parámetros y las instrucciones de verificación.La quinta es si investigadores independientes o auditores han revisado la configuración y el sistema de pruebas.La sexta es si las futuras actualizaciones requieren una nueva configuración.La séptima es si los usuarios pueden verificar los hashes de los parámetros comparándolos con las publicaciones oficiales.La octava es si el proyecto explica las consecuencias de que se comprometa la configuración.La novena es si el sistema dispone de un plan de respuesta de emergencia para las vulnerabilidades del sistema de pruebas.La décima es si el sistema de pruebas es adecuado para el valor que protege el protocolo.Estas preguntas ayudan a ir más allá de las afirmaciones de marketing y evaluar los verdaderos supuestos criptográficos.

Malentendidos habituales sobre CRS

Un malentendido es creer que un CRS debe permanecer en secreto.En la mayoría de los sistemas de pruebas, el CRS es público; el peligro reside en que la aleatoriedad secreta utilizada para generarlo no se destruya.Otro malentendido es pensar que todos los sistemas de conocimiento cero necesitan una configuración de confianza.Algunos sistemas de pruebas son transparentes y prescinden de las ceremonias de configuración de confianza.Un tercer malentendido es suponer que un único CRS sirve para todas las aplicaciones.Un CRS puede estar vinculado a un sistema de pruebas, una curva, el tamaño de un circuito o el diseño de una aplicación específica.Un cuarto malentendido es creer que una configuración de confianza es automáticamente insegura.Una ceremonia multipartita bien diseñada puede reducir la confianza necesaria si los atacantes desconocen al menos una contribución honesta.Un quinto malentendido es pensar que los usuarios no tienen que preocuparse por el CRS porque solo afecta a los desarrolladores.En realidad, el CRS puede influir en la seguridad de un protocolo de privacidad, un rollup, un bridge o una aplicación basada en pruebas.

Preguntas frecuentes

¿Qué significa CRS en el ámbito cripto?

CRS significa Common Reference String, un conjunto de datos de referencia públicos utilizado por algunos sistemas de pruebas de conocimiento cero para generar y verificar pruebas.

¿CRS es lo mismo que SRS?

CRS es el término más general, mientras que SRS suele ser una forma estructurada de CRS utilizada por determinados SNARK y esquemas de compromisos polinómicos.

¿Por qué necesitan un CRS los zk-SNARK?

Muchos zk-SNARK necesitan un CRS para que el prover y el verificador compartan parámetros públicos que permitan generar y verificar pruebas no interactivas.

¿Es privado el CRS?

No. El CRS suele ser público, pero en los sistemas con configuración de confianza debe destruirse la aleatoriedad secreta utilizada para generarlo.

¿Qué es el toxic waste en una configuración de confianza?

El toxic waste es el material secreto de configuración que, si lo conserva un atacante, podría permitirle crear pruebas falsas en algunos sistemas.

¿Qué es una ceremonia CRS?

Una ceremonia CRS es un proceso de configuración en el que uno o varios participantes generan la cadena de referencia pública de un sistema de pruebas.

¿Por qué se utilizan ceremonias multipartitas?

Se utilizan para reducir la dependencia de un solo participante de confianza durante la generación del CRS.

¿Necesitan los zk-STARK un CRS de confianza?

Por lo general, los zk-STARK se describen como sistemas de pruebas transparentes, porque no requieren un CRS de configuración de confianza como muchos sistemas zk-SNARK.

¿Puede un CRS defectuoso poner en riesgo los fondos cripto?

Sí. Un CRS comprometido puede ser peligroso si el protocolo acepta pruebas falsificadas que afectan a saldos, retiradas, reclamaciones de bridges o estados de rollups.

¿Cómo pueden comprobar los usuarios los supuestos de confianza del CRS?

Los usuarios pueden consultar la documentación del proyecto, los registros de la ceremonia, los hashes de los parámetros, las auditorías, los detalles del sistema de pruebas y los procedimientos de actualización.

Conclusión

CRS (Common Reference String) es un concepto fundamental de la criptografía de conocimiento cero y un tema de seguridad importante para los sistemas cripto modernos.Proporciona parámetros públicos compartidos que permiten a los provers crear pruebas y a los verificadores comprobarlas.En muchos sistemas zk-SNARK, el CRS se crea mediante una configuración de confianza, por lo que el proceso debe llevarse a cabo con sólidas medidas de seguridad y transparencia.Si se destruye el material secreto de configuración y la ceremonia está bien diseñada, un sistema basado en CRS puede permitir verificar pruebas compactas y de forma eficiente.Si el material secreto de configuración se ve comprometido, algunos sistemas pueden ser vulnerables a pruebas falsificadas.Por eso, el diseño del CRS importa para los protocolos de privacidad, los zk-rollups, los compromisos KZG, los bridges, los sistemas de identidad y otras aplicaciones cripto basadas en pruebas.La idea principal es que el CRS suele ser público, pero es necesario comprender la confianza que sustenta su generación.Quienes evalúen un proyecto cripto de conocimiento cero deben preguntarse cómo se generó el CRS, si la configuración es de confianza o transparente, si es universal o específica para un circuito y cómo se gestionarán los parámetros de prueba en futuras actualizaciones.