Prover

¿Qué es un prover en cripto?

Un prover es una persona, programa, nodo, servicio o sistema de hardware que genera una prueba criptográfica para demostrar que una afirmación, un cálculo, un lote de transacciones o una transición de estado es válido.

En las criptomonedas, el término se utiliza sobre todo en las pruebas de conocimiento cero, los validity rollups, las zkVM, los protocolos de privacidad y los sistemas de computación verificable.

La función del prover es realizar el intenso trabajo computacional necesario para crear una prueba que otra parte pueda verificar con menos recursos.

Esta otra parte se denomina verifier.

Un prover puede demostrar que algo se ha calculado correctamente sin obligar a cada verifier a repetir todo el cálculo.

Esta idea es importante para la escalabilidad de blockchain, ya que las blockchains públicas necesitan que muchos participantes estén de acuerdo sobre los cambios de estado válidos.

Si cada nodo tiene que volver a ejecutar todas las transacciones con todo detalle, la red puede volverse lenta y costosa.

Con los sistemas de pruebas, un prover puede ejecutar o comprobar una gran carga de trabajo off-chain y enviar una prueba compacta on-chain.

La documentación de Ethereum sobre las pruebas de conocimiento cero explica que la computación verificable permite a un nodo ejecutar una transacción fuera de Ethereum y enviar una prueba que demuestre que la ejecución off-chain fue correcta.

La forma más sencilla de entender qué es un prover es pensar en la máquina o el actor que crea el recibo matemático que demuestra que un cálculo se ha realizado correctamente.

Cómo funciona un prover

Un prover parte de una afirmación que debe demostrarse.

La afirmación puede ser sencilla, como demostrar que se conoce un valor secreto.

También puede ser compleja, como demostrar que miles de transacciones de Layer 2 se procesaron conforme a las reglas del protocolo.

El prover también utiliza datos de entrada.

Algunos datos pueden ser públicos, es decir, el verifier puede verlos.

Otros pueden ser privados, lo que significa que el prover los utiliza sin revelarlos directamente.

En muchos sistemas de pruebas, los datos de entrada privados se denominan witness.

A continuación, el prover aplica un algoritmo de generación de pruebas que transforma la afirmación, las restricciones, los datos de entrada públicos y el witness en una prueba.

La prueba suele ser mucho más pequeña y rápida de verificar que el cálculo original.

El verifier comprueba la prueba mediante un algoritmo de verificación.

Si la prueba es válida, el verifier acepta que la afirmación es verdadera conforme a las reglas del sistema de pruebas.

Esto permite a las blockchains confiar en el resultado de un cálculo sin confiar personalmente en el prover.

Prover frente a verifier

El prover y el verifier desempeñan funciones opuestas en un sistema de pruebas.

El prover crea la prueba.

El verifier comprueba la prueba.

El prover suele tener la tarea más difícil, ya que generar pruebas puede exigir muchos recursos computacionales.

La tarea del verifier suele ser más sencilla, porque la verificación de pruebas está diseñada para ser rápida y barata.

Esta asimetría resulta útil para las blockchains: un prover puede realizar un trabajo intenso off-chain, mientras que muchos nodos o contratos inteligentes pueden verificar el resultado de forma eficiente.

En un ZK-rollup, por ejemplo, el prover puede generar una prueba de validez para un gran lote de transacciones.

A continuación, un contrato verifier on-chain comprueba la prueba antes de aceptar la actualización de estado del rollup.

La documentación de Ethereum sobre los ZK-rollups explica que estos utilizan pruebas de validez para finalizar transacciones en Ethereum.

El verifier no necesita confiar en la honestidad del prover, ya que una prueba no válida debería fallar en la verificación.

Prover frente a sequencer

Un prover no es lo mismo que un sequencer.

Un sequencer ordena las transacciones y, por lo general, ayuda a crear lotes en un sistema de rollup.

Un prover genera la prueba criptográfica de que el lote o la transición de estado es válido.

En algunos sistemas, una misma organización puede operar tanto la infraestructura de secuenciación como la de generación de pruebas.

En otros, la secuenciación y la generación de pruebas pueden repartirse entre distintos servicios, nodos, mercados o participantes de la comunidad.

Esta distinción importa porque ordenar transacciones y demostrar que son correctas son facultades diferentes.

Un sequencer puede influir en el orden de las transacciones, la latencia y la experiencia de usuario.

Un prover puede influir en la disponibilidad de las pruebas, el momento de la finalidad y el coste de la infraestructura.

Un rollup puede ser técnicamente sólido y, aun así, afrontar riesgos de centralización si la generación de pruebas depende de un solo operador.

Investigaciones recientes, como el estudio sobre la generación comunitaria de pruebas de CrowdProve, analizan cómo el trabajo de generación de pruebas para ZK-rollups podría distribuirse entre muchos provers más pequeños, en lugar de depender únicamente de una infraestructura centralizada.

Prover en las pruebas de conocimiento cero

En las pruebas de conocimiento cero, el prover intenta convencer a un verifier de que una afirmación es verdadera sin revelar más información que la necesaria para demostrarlo.

El prover puede conocer un secreto privado, datos privados de una transacción, un atributo de identidad privado, el resultado de un cálculo privado o un witness privado.

La prueba solo debería revelar aquello que el sistema esté diseñado para revelar.

Por ejemplo, un usuario puede demostrar que conoce una contraseña válida sin revelarla.

En el ámbito cripto, un usuario puede demostrar que una transacción cumple las reglas sin revelar todos sus detalles privados.

No todas las pruebas utilizadas en los rollups tienen como objetivo principal proteger la privacidad.

Muchos rollups utilizan pruebas de validez principalmente para mejorar la escalabilidad y garantizar la corrección, no para ocultar todos los detalles de las transacciones.

Por eso, algunas personas utilizan el término más amplio «prueba de validez» cuando la prueba demuestra una ejecución correcta, en lugar de ofrecer privacidad total.

El prover sigue siendo el componente que genera la prueba.

Que la prueba se utilice para proteger la privacidad, mejorar la escalabilidad o ambas cosas depende del diseño del protocolo.

Prover en los ZK-rollups

En un ZK-rollup, el prover genera una prueba de que un lote de transacciones off-chain se procesó correctamente.

El rollup ejecuta muchas transacciones fuera de la cadena base.

Después, envía datos comprimidos y una prueba de validez a la cadena base.

La cadena base verifica la prueba en lugar de volver a ejecutar todas las transacciones del lote.

Esto puede reducir el cálculo on-chain y mejorar la escalabilidad.

El prover es una de las piezas más importantes de un ZK-rollup, ya que los usuarios dependen de las pruebas para finalizar las actualizaciones de estado.

Si la generación de pruebas es lenta, la finalidad puede retrasarse.

Si generar pruebas resulta costoso, los costes operativos del rollup pueden aumentar.

Si la generación de pruebas está centralizada, el rollup puede depender demasiado de un único proveedor de infraestructura.

Si falla la generación de pruebas, el rollup puede tener dificultades para enviar nuevas actualizaciones de estado válidas.

Por eso, el diseño, el rendimiento, la descentralización y la fiabilidad de los provers son temas clave en el desarrollo de Layer 2.

Prover en las zkVM

Una zkVM es una máquina virtual de conocimiento cero que puede demostrar la ejecución correcta de programas.

En vez de escribir un circuito personalizado para cada tarea, los desarrolladores pueden ejecutar código en una máquina virtual y generar una prueba de que se ha ejecutado correctamente.

La documentación para desarrolladores de RISC Zero describe la computación verificable como una forma de tener confianza criptográfica en que un algoritmo concreto ha generado una salida de datos específica.

En una zkVM, el prover ejecuta el programa, registra la ejecución y genera una prueba de esa ejecución.

Después, el verifier puede comprobar la prueba sin volver a ejecutar el programa completo.

Este modelo puede facilitar el desarrollo de ZK, ya que los desarrolladores pueden trabajar con lenguajes de programación conocidos o con destinos de máquina virtual.

Los provers de zkVM pueden utilizarse en rollups, bridges, sistemas de identidad, aplicaciones de privacidad, flujos de trabajo de IA verificable, videojuegos verificables y cálculos off-chain.

Sin embargo, generar pruebas con una zkVM puede requerir muchos recursos.

El rendimiento depende del tamaño del programa, el uso de memoria, el sistema de pruebas, el hardware, el diseño recursivo y las decisiones de optimización.

Prover en los sistemas STARK

Los sistemas basados en STARK utilizan un tipo de prueba que puede verificarse sin depender de las mismas hipótesis de trusted setup que emplean algunos otros sistemas de pruebas.

En un sistema STARK, el prover convierte un cálculo en una prueba basada en restricciones algebraicas y datos de traza.

La prueba puede demostrar que un programa o un lote de transacciones ha seguido las reglas exigidas.

La documentación de SHARP de Starknet describe los contratos verifier on-chain que verifican las pruebas STARK generadas por SHARP.

SHARP es un ejemplo de infraestructura de generación de pruebas compartida, capaz de agrupar y probar la ejecución de varios programas o aplicaciones.

Los provers STARK son conocidos por sus sólidas propiedades de escalabilidad y las ventajas que ofrece su transparencia.

Según la construcción, también pueden generar pruebas más grandes que algunos sistemas SNARK.

Como ocurre con cualquier sistema de pruebas, las ventajas e inconvenientes prácticos dependen del tiempo de generación, el coste de verificación, el tamaño de la prueba, las hipótesis de seguridad y la experiencia de desarrollo.

El prover absorbe gran parte de esta complejidad técnica para que el verifier pueda comprobar una prueba concisa.

Prover en los sistemas SNARK

Los sistemas SNARK utilizan pruebas sucintas que pueden ser muy pequeñas y rápidas de verificar.

En un sistema SNARK, el prover crea una prueba compacta de que un cálculo satisface un conjunto de restricciones.

Muchos sistemas SNARK requieren un trusted setup, aunque los diseños más recientes pueden reducir este requisito o modificarlo.

Un prover SNARK suele necesitar una proving key generada durante la configuración.

El verifier utiliza una verification key para comprobar la prueba.

Los provers SNARK pueden resultar útiles cuando el coste de verificación on-chain debe ser muy bajo.

Esto es importante porque las blockchains de capa base cobran comisiones por el cálculo y el almacenamiento.

Una prueba pequeña y barata de verificar puede hacer más prácticas las aplicaciones avanzadas.

Sin embargo, generar la prueba puede seguir siendo costoso para el prover.

El diseño de aplicaciones basadas en SNARK debe equilibrar el tamaño de la prueba, el tiempo de generación, las hipótesis del trusted setup y la complejidad del desarrollo.

Witness, datos de entrada públicos y privados

Un prover suele trabajar con datos de entrada tanto públicos como privados.

Los datos de entrada públicos son valores que el verifier puede ver.

Los datos de entrada privados son valores que utiliza el prover, pero que no revela directamente.

Los datos de entrada privados suelen denominarse witness.

Por ejemplo, en una prueba de identidad privada, el dato de entrada público podría ser el umbral de edad, mientras que el witness privado podría ser la fecha de nacimiento real del usuario o los datos de sus credenciales.

En una prueba de rollup, los datos de entrada públicos pueden incluir raíces de estado anteriores y nuevas, compromisos de lotes o parámetros del protocolo.

Según el diseño, el witness puede incluir detalles de transacciones, trazas de ejecución, rutas de Merkle, firmas o datos intermedios de cálculos.

El prover utiliza el witness para generar la prueba.

El verifier comprueba que la prueba coincide con los datos de entrada públicos.

Un sistema de pruebas seguro no debería permitir que el prover genere una prueba válida para una afirmación falsa.

Circuitos y restricciones

Muchos sistemas de pruebas requieren expresar un cálculo como un circuito o un conjunto de restricciones.

Un circuito describe lo que debe demostrarse en un formato que el sistema de pruebas pueda interpretar.

Las restricciones definen las reglas que deben cumplir los datos de entrada y los pasos del cálculo para que sean válidos.

Por ejemplo, un circuito puede exigir que un hash se haya calculado correctamente, que una firma sea válida o que una actualización de saldo siga las reglas del protocolo.

El prover debe demostrar que existe un witness que satisface todas las restricciones.

Si el witness no satisface las restricciones, el prover no debería poder generar una prueba válida.

Diseñar circuitos es una de las tareas más difíciles del desarrollo de ZK.

Un circuito mal escrito puede demostrar por accidente algo distinto de lo previsto.

Un circuito también puede ser correcto, pero ineficiente, lo que ralentiza la generación de pruebas o la encarece.

Un buen rendimiento del prover suele empezar con un buen diseño del circuito.

Trazas de ejecución

Algunos sistemas de pruebas utilizan trazas de ejecución en lugar de los circuitos tradicionales específicos para cada aplicación.

Una traza de ejecución registra los pasos computacionales realizados por un programa o una máquina virtual.

El prover utiliza la traza para demostrar que cada paso ha seguido las reglas de la máquina o el protocolo.

Este modelo es habitual en los sistemas STARK y zkVM.

La generación de trazas puede convertirse en un importante cuello de botella de rendimiento, ya que los programas grandes pueden producir trazas extensas.

La investigación reciente sobre máquinas virtuales ZK se ha centrado en mejorar la generación de trazas, los procesos de generación de pruebas y la aceleración por hardware.

Las trazas eficientes ayudan a reducir el coste y la latencia del prover.

En los rollups, una generación de trazas más rápida puede permitir enviar las pruebas antes y acelerar la liquidación.

En las aplicaciones, las trazas más rápidas pueden hacer que la computación verificable sea más práctica para los usuarios reales.

El prover se encarga de convertir la ejecución sin procesar en datos listos para generar pruebas.

Rendimiento del prover

El rendimiento del prover es uno de los aspectos prácticos más importantes de los sistemas cripto de conocimiento cero.

Generar pruebas puede requerir muchos recursos de CPU, GPU, memoria, almacenamiento y hardware especializado.

Algunos sistemas de pruebas permiten generar pruebas con mayor rapidez, pero son más lentos de verificar.

Otros tardan más en generar las pruebas, pero producen pruebas más pequeñas o más baratas.

Los equipos de rollups suelen dedicar mucho esfuerzo de ingeniería a optimizar los procesos de generación de pruebas.

Un prover más rápido puede reducir los retrasos en la liquidación.

Un prover más barato puede reducir los costes para los usuarios.

Un prover más escalable puede admitir más transacciones y aplicaciones más complejas.

El rendimiento del prover también influye en la descentralización: si generar pruebas requiere hardware muy caro, menos participantes podrán operar provers.

Esto puede aumentar la dependencia de operadores especializados.

Descentralización de los provers

La descentralización de los provers significa que la generación de pruebas no está controlada por una sola parte.

En los primeros sistemas ZK, la infraestructura de generación de pruebas suele estar centralizada porque la tecnología es compleja y cara de operar.

Con el tiempo, muchos proyectos aspiran a distribuir más esta tarea.

La generación distribuida de pruebas puede implicar varios provers, mercados de pruebas, redes de generación compartida, participación comunitaria o competencia entre proveedores de hardware.

La generación descentralizada de pruebas puede reducir el riesgo de censura, el riesgo de falta de actividad y la dependencia de un único operador.

Sin embargo, también plantea retos de coordinación.

El sistema debe asignar tareas de generación de pruebas, verificar el trabajo de los provers, pagarles, evitar el spam, gestionar las tareas fallidas y proteger los datos confidenciales del witness cuando sea necesario.

La investigación sobre la generación comunitaria de pruebas estudia si muchas máquinas pequeñas pueden ayudar a producir pruebas para los rollups.

Esto podría abrir la infraestructura de generación de pruebas si los aspectos económicos y de seguridad funcionan correctamente.

La descentralización de los provers no es solo una cuestión técnica: también depende de los incentivos, la gobernanza, el acceso al hardware y la facilidad de uso del software.

Mercados de provers

Un mercado de provers es un sistema en el que distintos provers compiten o colaboran para generar pruebas para aplicaciones.

Un rollup, un bridge, una aplicación zkVM o un sistema de privacidad pueden enviar una tarea de generación de pruebas a una red de provers.

Los provers pueden pujar por la tarea o ser seleccionados según las reglas del protocolo.

Cuando un prover genera una prueba válida, puede recibir un pago.

Los mercados de provers pueden ayudar a reducir los costes al fomentar la competencia.

También pueden mejorar la fiabilidad, ya que las aplicaciones no dependen de un único servidor de generación de pruebas.

Sin embargo, estos mercados necesitan una verificación sólida para rechazar las pruebas no válidas y gestionar los trabajos fallidos.

También necesitan proteger la privacidad cuando las tareas de generación de pruebas contienen datos confidenciales del witness.

Algunas tareas pueden externalizarse de forma segura porque solo incluyen datos públicos.

Otras requieren computación confidencial, witnesses cifrados, hardware de confianza o un diseño cuidadoso del protocolo.

Generación recursiva de pruebas

La generación recursiva de pruebas consiste en utilizar una prueba para verificar otra prueba y, después, demostrar que esa verificación es correcta.

Puede parecer abstracto, pero resulta muy útil en los sistemas de escalabilidad.

Un prover puede generar muchas pruebas pequeñas y combinarlas después en una prueba más grande.

Esto puede abaratar la verificación y reducir la cantidad de datos que se envían on-chain.

Las pruebas recursivas pueden ayudar a los rollups a agrupar muchos lotes de transacciones.

También pueden ayudar a las zkVM a demostrar cálculos largos en bloques más pequeños.

La generación recursiva de pruebas puede mejorar la escalabilidad, pero añade complejidad técnica.

El proceso del prover debe gestionar la composición de pruebas, los circuitos de verificación, los calendarios de agregación y los equilibrios de rendimiento.

El diseño de las pruebas recursivas también puede afectar a la latencia, porque la prueba final puede depender de que primero se completen pruebas anteriores.

Los usuarios apenas perciben la generación recursiva de pruebas, pero esta puede afectar a la velocidad, las comisiones y la finalidad.

Agregación de pruebas

La agregación de pruebas consiste en combinar varias pruebas en una sola prueba o en un único proceso de verificación.

Un prover o agregador puede tomar muchas pruebas individuales y crear una única prueba que las represente a todas.

Esto puede reducir los costes de verificación on-chain, ya que la cadena base verifica una prueba agregada en vez de muchas pruebas independientes.

La agregación resulta útil para rollups, pools de privacidad, liquidaciones por lotes y sistemas de mensajería cross-chain.

También puede respaldar una infraestructura compartida de generación de pruebas que beneficie a varias aplicaciones.

La contrapartida es que la agregación puede introducir retrasos, porque quizá el sistema tenga que esperar a disponer de suficientes pruebas para agruparlas.

También puede crear dependencia del agregador o del servicio compartido de generación de pruebas.

Un buen diseño de agregación equilibra la eficiencia, la latencia, la descentralización y la fiabilidad.

La agregación de pruebas es una de las razones por las que los provers se están convirtiendo en una capa de infraestructura importante en el sector cripto.

Cuantas más aplicaciones utilicen pruebas ZK, más valiosa será una agregación eficiente.

Disponibilidad operativa de los provers

La disponibilidad operativa de un prover es la capacidad del sistema de generación de pruebas para seguir produciéndolas cuando se necesitan.

Si un rollup necesita pruebas para finalizar lotes, el tiempo de inactividad del prover puede retrasar la liquidación.

Si un bridge necesita pruebas para liberar fondos, el tiempo de inactividad del prover puede retrasar las retiradas.

Si una aplicación de privacidad necesita pruebas para las acciones de los usuarios, el tiempo de inactividad del prover puede impedir que completen transacciones.

La disponibilidad no depende únicamente de que el sistema de pruebas sea matemáticamente seguro.

También depende de que la infraestructura real pueda seguir funcionando ante una carga elevada, interrupciones, ataques y fallos de hardware.

La disponibilidad de los provers puede mejorarse mediante redundancia, generación distribuida de pruebas, colas de tareas, provers de respaldo, monitorización y procedimientos de emergencia claros.

Los usuarios deben entender que un sistema ZK puede minimizar la confianza necesaria para garantizar la corrección y, aun así, depender de la infraestructura de generación de pruebas para operar a tiempo.

Una prueba válida no sirve de nada si nadie la genera.

Por eso, la operativa de los provers forma parte de la fiabilidad del protocolo.

Solidez de los provers

La solidez es la propiedad que impide que un prover deshonesto convenza a un verifier de que una afirmación falsa es verdadera.

En el ámbito cripto, la solidez es fundamental, ya que una prueba falsa podría permitir transiciones de estado no válidas, retiradas falsas, saldos incorrectos o acciones no autorizadas.

Un sistema de pruebas con una solidez débil sería peligroso, aunque fuese rápido.

La solidez depende de las hipótesis criptográficas, la calidad de la implementación, la elección de parámetros, la corrección del circuito y la del verifier.

El prover puede actuar de forma maliciosa, pero el verifier debería rechazar las pruebas no válidas.

Esta es la principal razón por la que los sistemas de pruebas son tan potentes.

El protocolo no necesita confiar en la honestidad del prover.

Solo necesita que el sistema de pruebas y el verifier sean seguros.

Sin embargo, si el circuito demuestra algo distinto de lo previsto, la prueba puede ser válida para ese circuito y, aun así, no proteger la aplicación.

La solidez debe tenerse en cuenta tanto en el sistema de pruebas como en el diseño de la aplicación.

Completitud de los provers

La completitud significa que un prover honesto debería poder generar una prueba para una afirmación verdadera.

Si un cálculo es válido y el prover cuenta con el witness correcto, el sistema de generación de pruebas debería producir una prueba que el verifier acepte.

La completitud es importante porque un sistema que rechaza pruebas válidas o no puede generarlas de forma fiable no resulta práctico.

En los rollups, una completitud deficiente podría impedir que se finalicen lotes válidos de transacciones.

En las aplicaciones de privacidad, podría impedir que usuarios honestos demuestren acciones válidas.

En las zkVM, podría hacer que no se pudieran generar pruebas de programas correctos debido a errores de implementación o límites de recursos.

La completitud depende de un software correcto, memoria y capacidad de cálculo suficientes, parámetros de prueba compatibles e infraestructura estable.

En la práctica, los desarrolladores prueban a fondo los sistemas de generación de pruebas para garantizar que puedan demostrar de forma fiable cargas de trabajo válidas.

Un prover debe ser seguro frente a las pruebas falsas y, a la vez, práctico para generar pruebas verdaderas.

Un buen diseño de prover equilibra la seguridad y la facilidad de uso.

Conocimiento cero en los provers

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

Esta propiedad importa cuando el witness contiene datos privados.

Un prover puede conocer una clave secreta, el importe oculto de una transacción, un atributo de identidad privado o un dato de entrada confidencial de un cálculo.

Una prueba de conocimiento cero debería permitir al prover demostrar la afirmación requerida sin revelar ese secreto.

No todas las pruebas de validez utilizadas en el ámbito cripto necesitan ofrecer una privacidad sólida.

Algunos sistemas utilizan esta tecnología principalmente para abaratar la verificación.

Cuando se necesita privacidad, los desarrolladores deben diseñar cuidadosamente los circuitos, los datos de entrada públicos, la gestión de metadatos y las interfaces de usuario.

Una prueba puede ser de conocimiento cero y, aun así, los datos que la rodean pueden revelar información.

Por ejemplo, los patrones de uso, las direcciones de wallet, los datos IP o los patrones de transacciones pueden seguir revelando el comportamiento de los usuarios.

El prover puede proteger matemáticamente el witness, pero la aplicación completa debe proteger la privacidad en la práctica.

Hardware para provers

Según el sistema de pruebas y la carga de trabajo, los provers pueden utilizar CPU, GPU, FPGA, ASIC o infraestructura en la nube.

La generación de pruebas puede implicar grandes operaciones matemáticas, como aritmética de cuerpos finitos, compromisos polinómicos, hashing, transformadas rápidas de Fourier y procesamiento de trazas.

Estas tareas pueden beneficiarse de la paralelización y del hardware especializado.

La aceleración por hardware puede reducir el tiempo y el coste de generación de pruebas.

También puede ejercer presión hacia la centralización si solo los operadores con muchos recursos pueden permitirse el mejor hardware para generar pruebas.

Algunos proyectos intentan reducir este problema mejorando la eficiencia del software y ofreciendo compatibilidad con hardware convencional.

Otros utilizan clústeres especializados para lograr una gran capacidad de procesamiento.

La elección del hardware depende de los objetivos de la red.

Un sistema diseñado para maximizar la capacidad de procesamiento puede aceptar una infraestructura de generación de pruebas más especializada.

Un sistema diseñado para facilitar una participación amplia puede priorizar diseños de provers que funcionen en máquinas más accesibles.

Comisiones y economía de los provers

Operar provers tiene un coste.

Requieren hardware, electricidad, ancho de banda, ingeniería, mantenimiento y monitorización.

En un rollup, los costes de generación de pruebas pueden pagarse con las comisiones de transacción, los ingresos del protocolo, las subvenciones o los fondos del operador.

En un mercado de provers, se puede pagar directamente a los provers por completar tareas de generación de pruebas.

La economía de los provers es importante porque unos costes elevados pueden aumentar las comisiones para los usuarios.

También pueden limitar qué aplicaciones resultan viables.

Un videojuego, una aplicación social o un sistema de pagos de bajo valor quizá no funcionen bien si cada acción requiere una generación de pruebas costosa.

Los desarrolladores suelen optimizar los circuitos, agrupar tareas, agregar pruebas y utilizar recursividad para reducir el coste de generación por transacción.

Puede que los usuarios no vean directamente las comisiones de los provers, pero pueden notarlas en los costes de transacción, los retrasos en la liquidación o los límites de las aplicaciones.

Una generación eficiente de pruebas es una de las claves para que las aplicaciones ZK lleguen al público general.

Riesgos de seguridad de los provers

El primer riesgo de los provers son los errores de implementación.

Un prover con errores puede generar pruebas incorrectas, fallar bajo carga o exponer datos confidenciales del witness.

El segundo riesgo es la generación centralizada de pruebas.

Si solo un operador puede generarlas, el sistema puede sufrir interrupciones o censura si dicho operador falla.

El tercer riesgo es la filtración del witness.

Si un servicio de generación de pruebas recibe datos de entrada privados, una seguridad deficiente podría exponer los datos de los usuarios.

El cuarto riesgo son los errores en los circuitos.

Un prover puede generar una prueba válida para un circuito incorrecto si este no aplica las reglas previstas.

El quinto riesgo es que el hardware se vea comprometido.

Las máquinas de generación de pruebas comprometidas pueden filtrar secretos, retrasar tareas o atacar la infraestructura de la aplicación.

El sexto riesgo es el fracaso económico.

Si los provers no reciben una compensación suficiente, puede que la capacidad disponible para generar pruebas sea insuficiente.

El séptimo riesgo son las actualizaciones.

Los cambios en el software de generación de pruebas, los circuitos o los contratos verifier pueden introducir nuevas vulnerabilidades.

Provers y disponibilidad de los datos

Un prover demuestra que algo es correcto, pero no garantiza automáticamente la disponibilidad de los datos.

La disponibilidad de los datos significa que los usuarios o nodos pueden acceder a los datos de transacciones o de estado necesarios para reconstruir o verificar el estado del sistema.

Esta distinción es importante en los rollups.

Una prueba de validez puede demostrar que una transición de estado es válida, pero los usuarios también necesitan suficientes datos para conocer sus saldos, retirar sus posiciones o reconstruir el estado.

Los distintos diseños de rollups y de escalabilidad gestionan la disponibilidad de los datos de formas diferentes.

Algunos publican los datos en una cadena base.

Otros utilizan capas de disponibilidad de datos independientes.

Otros recurren a comités u otros modelos.

El prover se encarga de demostrar una afirmación, no de resolver por sí solo todos los problemas de disponibilidad.

Un sistema de escalabilidad seguro necesita tanto pruebas válidas como datos disponibles.

Provers y finalidad

La finalidad significa que una transacción o actualización de estado se acepta como liquidada conforme a las reglas de la red.

En los sistemas basados en pruebas de validez, el tiempo que se tarda en generarlas puede afectar a la finalidad.

Un lote puede ejecutarse rápidamente en una Layer 2, pero la liquidación final en la cadena base puede esperar a que se genere una prueba.

Si el prover es rápido, la liquidación puede producirse antes.

Si el prover es lento o está sobrecargado, los usuarios pueden tener que esperar más para recibir la confirmación final o realizar retiradas.

Las pruebas recursivas y la agregación pueden mejorar la eficiencia, pero también pueden añadir retrasos mientras se agrupan las pruebas.

La finalidad también depende del tiempo de bloque de la cadena base, sus reglas de confirmación y la ejecución del contrato verifier.

El prover es solo una parte del proceso de finalidad.

Aun así, la velocidad del prover suele ser uno de los cuellos de botella más visibles en los sistemas ZK.

Unos provers mejores pueden hacer que las aplicaciones ZK parezcan más rápidas y fiables.

Provers y bridges

Los provers pueden utilizarse en bridges para demostrar eventos, transiciones de estado o mensajes de una cadena a otra.

Un bridge basado en pruebas puede permitir que una cadena verifique hechos sobre otra sin confiar en un grupo central de firmantes.

Por ejemplo, un prover puede generar una prueba de que una transacción, raíz de estado o mensaje determinado era válido en una cadena de origen.

Después, un contrato verifier de la cadena de destino puede comprobar la prueba.

Esto puede reducir las hipótesis de confianza en comparación con algunos modelos de bridges.

Sin embargo, los bridges basados en pruebas siguen siendo complejos.

Deben gestionar las reorganizaciones de cadena, las hipótesis de finalidad, la corrección del verifier, la disponibilidad de datos, el coste de las pruebas y los riesgos de actualización.

Un prover puede mejorar las hipótesis de confianza de un bridge, pero no hace que su diseño sea automáticamente seguro.

Los usuarios deberían seguir considerando los sistemas cross-chain como una infraestructura de alto riesgo.

La seguridad de un bridge depende de toda su arquitectura, no solo de que incluya un prover.

Provers y privacidad

En las aplicaciones cripto centradas en la privacidad, el prover puede ayudar a los usuarios a demostrar que cumplen las reglas sin revelar información confidencial.

Por ejemplo, un usuario puede demostrar que posee una credencial sin revelar la credencial completa.

También puede demostrar que el saldo de una transacción es válido sin revelar todos los detalles privados de esta.

Asimismo, puede demostrar que pertenece a un grupo sin revelar qué miembro es exactamente.

El prover crea la prueba utilizando datos de entrada privados.

El verifier la comprueba utilizando reglas públicas.

Esto permite una divulgación selectiva.

Sin embargo, la privacidad depende de algo más que de la prueba.

Los metadatos, la actividad de red, los horarios, la reutilización de direcciones, la identificación del navegador y los registros de la aplicación todavía pueden filtrar información.

Un sistema de privacidad sólido debe proteger toda la experiencia del usuario, no solo el witness criptográfico.

Provers y cumplimiento normativo

Los provers pueden facilitar diseños cripto compatibles con el cumplimiento normativo al demostrar hechos sin revelar datos privados innecesarios.

Por ejemplo, un usuario puede demostrar que cumple un requisito de elegibilidad sin publicar en la blockchain un documento de identidad completo.

Un protocolo puede demostrar que un cálculo ha seguido un conjunto de reglas sin exponer datos comerciales privados.

Una aplicación financiera puede demostrar que una transición de estado respeta las reglas contables sin publicar todos sus registros internos.

Esto no significa que las pruebas de conocimiento cero resuelvan automáticamente todos los problemas de cumplimiento normativo.

Los requisitos legales varían según la jurisdicción y el caso de uso.

Algunas normas pueden seguir exigiendo el mantenimiento de registros, auditorías, verificaciones de identidad, informes o divulgaciones.

Un prover puede reducir la exposición de datos innecesaria, pero no sustituye al análisis jurídico.

Un buen diseño de cumplimiento debería combinar criptografía, políticas, gobernanza y consentimiento del usuario.

Los provers permiten la verificación selectiva, pero sigue correspondiendo a las personas decidir qué debe demostrarse.

Ventajas de los provers

La primera ventaja de un prover es la escalabilidad.

Un prover puede comprimir cálculos grandes en pruebas más baratas de verificar.

La segunda ventaja es la privacidad.

Cuando el sistema de pruebas está diseñado para ofrecer conocimiento cero, un prover puede demostrar hechos sobre datos privados sin revelar esos datos.

La tercera ventaja es la minimización de la confianza.

Los verifiers no necesitan confiar en la honestidad del prover si rechazan las pruebas no válidas.

La cuarta ventaja es la interoperabilidad.

Las pruebas pueden ayudar a un sistema a verificar hechos sobre otro.

La quinta ventaja es la auditabilidad.

Una prueba puede ofrecer evidencia matemática de que un cálculo ha seguido reglas definidas.

La sexta ventaja es la automatización.

Los contratos inteligentes pueden verificar pruebas y actuar en función de ellas sin una revisión manual.

La séptima ventaja es la eficiencia.

La agregación y la recursividad pueden reducir los costes de verificación repetida en muchas transacciones o aplicaciones.

Limitaciones de los provers

La primera limitación es el coste.

Generar pruebas puede exigir muchos recursos computacionales.

La segunda limitación es la latencia.

La generación de pruebas puede llevar tiempo y retrasar la liquidación o las retiradas.

La tercera limitación es la complejidad.

Los sistemas de provers requieren conocimientos especializados de criptografía, ingeniería y revisión de seguridad.

La cuarta limitación es la presión hacia la centralización.

Los elevados requisitos de hardware pueden dificultar que muchos actores independientes operen provers.

La quinta limitación es la dependencia del circuito.

Una prueba solo demuestra aquello que comprueba realmente el circuito o el programa.

La sexta limitación es la filtración de privacidad fuera de la prueba.

Una prueba de conocimiento cero no oculta automáticamente los metadatos ni compensa un mal diseño de la aplicación.

La séptima limitación son los riesgos de actualización.

Modificar el software de generación de pruebas, los circuitos o los contratos verifier puede introducir nuevas hipótesis de seguridad.

Cómo deberían entender los provers los usuarios

La mayoría de los usuarios no interactúa directamente con los provers.

Interactúa con wallets, rollups, bridges, aplicaciones de privacidad o aplicaciones descentralizadas que utilizan provers en segundo plano.

Aun así, los usuarios deberían entender la función del prover, ya que afecta a la velocidad, las comisiones, la finalidad y las hipótesis de confianza.

Si un rollup depende de un único prover centralizado, los usuarios deberían saber qué ocurre si este deja de funcionar.

Si una aplicación de privacidad utiliza un servicio remoto de generación de pruebas, los usuarios deberían saber si se envían datos privados a ese servicio.

Si un bridge depende de pruebas, los usuarios deberían entender qué verifica la prueba y qué no.

También deberían comprobar si se ha auditado el contrato verifier y si el sistema de generación de pruebas cuenta con un modelo de seguridad claro.

La presencia de un prover no garantiza mágicamente la seguridad.

Un prover solo es valioso si el sistema de pruebas, el circuito, el verifier, la disponibilidad de los datos y la gobernanza están bien diseñados.

Los usuarios deberían considerar la generación de pruebas como una capa de seguridad, no como el sistema completo.

Buenas prácticas para desarrolladores

Los desarrolladores deberían definir claramente la afirmación que debe demostrar el prover.

Deberían diseñar circuitos o programas que apliquen exactamente las reglas previstas.

Deberían utilizar sistemas de generación de pruebas bien revisados y evitar la criptografía personalizada salvo que cuenten con la revisión de expertos.

Deberían probar la generación de pruebas con cargas de trabajo realistas, casos límite y condiciones de fallo.

Deberían evaluar el tiempo de generación de pruebas, el uso de memoria, los requisitos de hardware y el coste de verificación.

Deberían proteger los witnesses privados cuando la generación de pruebas incluya datos confidenciales de los usuarios.

Deberían documentar los datos de entrada públicos para que los usuarios y auditores entiendan qué comprueba realmente el verifier.

Cuando sea posible, deberían separar la infraestructura del prover de las facultades de administración sujetas a confianza.

Deberían planificar cómo gestionar las interrupciones del prover, los reintentos de tareas, la monitorización y las alternativas de emergencia.

Deberían comunicar los riesgos de actualización al modificar circuitos, proving keys, contratos verifier o el software del prover.

Malentendidos habituales sobre los provers

Un malentendido es creer que necesariamente hay que confiar en el prover.

En un sistema de pruebas bien diseñado, el verifier debería rechazar las pruebas no válidas aunque el prover actúe de forma deshonesta.

Otro malentendido es pensar que un prover siempre protege la privacidad.

Algunos provers generan pruebas de validez para mejorar la escalabilidad sin ocultar todos los datos de las transacciones.

Otro malentendido es creer que generar pruebas es barato.

La generación de pruebas puede ser mucho más costosa que su verificación y puede requerir infraestructura especializada.

Otro malentendido es creer que una prueba válida demuestra todo lo relacionado con una aplicación.

Una prueba solo demuestra la afirmación específica codificada en el circuito o el programa.

Otro malentendido es creer que la descentralización de los provers ya se ha resuelto en todas partes.

Muchos sistemas aún trabajan para conseguir una infraestructura de generación de pruebas más abierta y descentralizada.

Otro malentendido es creer que los usuarios nunca tienen que preocuparse por los provers.

Puede que los usuarios no los operen, pero su diseño puede afectar a las retiradas, la finalidad, las comisiones, la privacidad y la fiabilidad de las aplicaciones.

Preguntas frecuentes

¿Qué significa prover en cripto?

Un prover es el actor, programa, nodo o servicio que genera una prueba criptográfica para demostrar que una afirmación, un cálculo o una transición de estado es válido.

¿Qué es un prover en una prueba de conocimiento cero?

En una prueba de conocimiento cero, el prover crea una prueba que convence al verifier de que una afirmación es verdadera sin revelar información privada innecesaria.

¿Cuál es la diferencia entre un prover y un verifier?

El prover crea la prueba, mientras que el verifier comprueba si es válida.

¿Por qué son importantes los provers para los ZK-rollups?

Los provers son importantes para los ZK-rollups porque generan pruebas de validez que permiten liquidar lotes de transacciones en una cadena base sin que cada nodo tenga que volver a ejecutar todas las transacciones.

¿Un prover es lo mismo que un sequencer?

No. Un sequencer ordena las transacciones, mientras que un prover genera pruebas criptográficas de que la ejecución es correcta o las transiciones de estado son válidas.

¿Un prover oculta siempre los datos privados?

No. Algunos provers se utilizan principalmente para mejorar la escalabilidad y garantizar la corrección, mientras que la privacidad depende de que el sistema de pruebas y la aplicación estén diseñados para ofrecer conocimiento cero.

¿Puede un prover deshonesto crear pruebas falsas?

Un sistema de pruebas seguro debería impedir que un prover deshonesto genere una prueba válida para una afirmación falsa.

¿Por qué es costoso generar pruebas?

La generación de pruebas puede ser costosa porque puede requerir cálculos extensos, generación de trazas que consume mucha memoria, operaciones polinómicas, hashing, recursividad y hardware especializado.

¿Qué es un witness en la generación de pruebas?

Un witness son los datos privados o internos que utiliza el prover para generar una prueba, sin necesidad de revelárselos al verifier.

¿Qué es la generación recursiva de pruebas?

Es el proceso de demostrar que otra prueba es válida, lo que puede ayudar a combinar muchas pruebas en otra más pequeña o eficiente.

¿Qué ocurre si el prover de un rollup deja de funcionar?

Si el rollup depende de ese prover, el envío de pruebas y la liquidación final pueden retrasarse hasta que se restablezca la capacidad de generación o se utilice un prover de respaldo.

¿Es posible descentralizar los provers?

Sí. La generación descentralizada de pruebas es un campo activo de desarrollo e investigación, pero requiere soluciones para la asignación de tareas, los pagos, la fiabilidad, la privacidad y la verificación.

Conclusión

Un prover es una de las funciones de infraestructura más importantes de los sistemas modernos de pruebas cripto.

Genera pruebas criptográficas que permiten a los verifiers confirmar afirmaciones, cálculos, lotes de transacciones o transiciones de estado sin repetir todo el trabajo subyacente.

Los provers son fundamentales para las pruebas de conocimiento cero, los ZK-rollups, las zkVM, los sistemas STARK y SNARK, la agregación de pruebas, la generación recursiva de pruebas, los protocolos de privacidad, los bridges y la computación verificable.

El principal valor de un prover es que traslada los cálculos más exigentes lejos del verifier, sin dejar de permitir una verificación fiable.

Esto puede mejorar la escalabilidad, reducir el trabajo on-chain, facilitar la privacidad y permitir nuevos diseños de aplicaciones.

Sin embargo, los provers también plantean retos reales.

Generar pruebas puede ser costoso, lento, exigir mucho hardware, resultar complejo desde el punto de vista operativo y, en ocasiones, estar centralizado.

La utilidad de una prueba depende de la afirmación que demuestra, el circuito o programa que comprueba, el verifier que la valida y la infraestructura que mantiene activa la generación de pruebas.

Para los usuarios, la lección más importante es que un prover ayuda a que la verificación criptográfica sea eficiente, pero no elimina todos los riesgos de un rollup, bridge, aplicación de privacidad o sistema de contratos inteligentes.

Para los desarrolladores, la lección más importante es que el diseño del prover debe ser seguro, eficiente, estar bien probado, tener en cuenta la privacidad y documentarse claramente.

La forma más sencilla de entender qué es un prover es pensar que realiza el trabajo matemático difícil para que el resto de la red cripto pueda verificar el resultado rápidamente y sin necesidad de confiar en nadie.