Pruebas descentralizadas, mercados de prueba e infraestructura ZK

Autor: Figment Capital Compilador: Block unicorn

introducción:

La tecnología de conocimiento cero (ZK) está mejorando rápidamente. A medida que avance la tecnología, surgirán más aplicaciones ZK, lo que impulsará una mayor demanda de generación de prueba de conocimiento cero (ZKP).

Actualmente, la mayoría de las aplicaciones ZK son protocolos para la protección de la privacidad. Las pruebas generadas por aplicaciones de privacidad como ZCash y TornadoCash son generadas localmente por el usuario, ya que generar un ZKP requiere el conocimiento de la entrada secreta. Estos cálculos son relativamente pequeños y se pueden generar en hardware de consumo. Nos referimos a las pruebas ZK generadas por el usuario como pruebas del cliente.

Si bien la generación de algunas pruebas puede ser relativamente ligera, otras requieren cálculos más complejos. Por ejemplo, los paquetes acumulativos de validez (es decir, zkRollup) pueden requerir la prueba de miles de transacciones en una máquina virtual ZK (zkVM), lo que requiere más recursos informáticos y, por lo tanto, lleva más tiempo probar. Generar pruebas de estos grandes cálculos requiere máquinas potentes. Afortunadamente, dado que estas pruebas se basan únicamente en la simplicidad de las pruebas de conocimiento cero en lugar del conocimiento cero (sin entrada secreta), la generación de pruebas se puede subcontratar de forma segura a terceros, y probaremos la generación que se externaliza (externaliza el cálculo necesario para demostrar a una nube u otro actor) la generación se denomina prueba del lado del servidor.

Bloquear notas de unicornio: la diferencia entre pruebas de conocimiento cero y conocimiento cero. Conocimiento cero es un marco de tecnología de privacidad básico, lo que significa que en el proceso de comunicación, el probador demuestra la autenticidad del evento al verificador sin revelar ninguna información, protegiendo así la privacidad.

La prueba de conocimiento cero es una herramienta criptográfica que se utiliza para probar la exactitud de una afirmación sin revelar ninguna información adicional sobre la afirmación. Es una técnica basada en algoritmos matemáticos y protocolos para probar a otros la verdad de una afirmación sin exponer información sensible. La prueba de conocimiento cero permite que el probador proporcione una prueba al verificador, y el verificador puede verificar la corrección de la prueba, pero no puede obtener la información específica detrás de la prueba.

En resumen, el conocimiento cero es un concepto general que se refiere a mantener la confidencialidad de la información en el proceso de interacción o prueba, y la prueba de conocimiento cero es una tecnología criptográfica específica utilizada para lograr una prueba de interacción de conocimiento cero.

Bloquear notas de unicornio En el texto, los términos "probador" y "validador" tienen diferentes significados.

Prover: se refiere a la entidad que realiza tareas específicas de generación de pruebas. Son responsables de generar pruebas de conocimiento cero para verificar y probar cálculos o transacciones específicas. El certificador puede ser un nodo informático que se ejecuta en una red descentralizada o hardware especializado. dispositivos.

Verificador: se refiere a los nodos que participan en el mecanismo de consenso de blockchain, encargados de verificar y verificar la validez de las transacciones y bloques, y participando en el proceso de consenso. Los validadores generalmente necesitan prometer una cierta cantidad de tokens como garantía de seguridad y son recompensados en proporción a la cantidad comprometida. Los validadores no necesariamente realizan tareas específicas de generación de pruebas directamente, pero garantizan la seguridad y la integridad de la red al participar en el consenso.

Demostración del lado del servidor

Las pruebas del lado del servidor se utilizan en muchas aplicaciones de blockchain, que incluyen:

1. Escalabilidad: las tecnologías Efficiency Rollup como Starknet, zkSync y Scroll amplían las capacidades de Ethereum al mover la computación fuera de la cadena.

** 2. Interoperabilidad entre cadenas: ** Las pruebas se pueden usar para promover una comunicación de confianza mínima entre diferentes cadenas de bloques para lograr una transmisión segura de datos y activos. Entre los equipos se encuentran Polymer, Polyhedra, Herodotus y Succinct.

**3. Middleware sin confianza: **Los proyectos de middleware como RiscZero e HyperOracle aprovechan las pruebas de conocimiento cero para proporcionar acceso a computación y datos fuera de la cadena sin confianza.

**4. L1 concisa (cadena pública de una capa basada en ZKP): **Las cadenas de bloques concisas similares a Mina y Repyh usan SNARK recursivas, lo que permite a los usuarios con poca potencia informática verificar el estado de forma independiente.

Ahora que se han desarrollado muchos de los requisitos previos de criptografía, herramientas y hardware, las aplicaciones que utilizan pruebas del lado del servidor finalmente están comenzando a llegar al mercado. En los próximos años, las pruebas del lado del servidor crecerán exponencialmente, lo que requerirá el desarrollo de nueva infraestructura y operadores que puedan generar de manera eficiente estas pruebas computacionalmente intensivas.

Aunque centralizado en la fase inicial, la mayoría de las aplicaciones que utilizan pruebas del lado del servidor tienen el objetivo a largo plazo de descentralizar el papel del probador. Al igual que con otros componentes de la pila de infraestructura, como los validadores y los encargados de pedidos, la descentralización efectiva del rol del probador requerirá un protocolo cuidadoso y un diseño de incentivos.

En este artículo, exploramos el diseño de redes de probadores. Primero diferenciamos entre redes de prueba y mercados de prueba. Una red de prueba es una colección de probadores que sirven una sola aplicación, como Validity Rollup. El mercado de prueba es un mercado abierto donde múltiples aplicaciones pueden enviar solicitudes de cálculos verificables. A continuación, proporcionamos una descripción general de los modelos de red de prueba de prueba descentralizados actuales y, a continuación, compartimos algunas posibilidades preliminares para el diseño de prueba de mercado, un área que todavía está poco explotada. Finalmente, discutimos los desafíos de operar una infraestructura de conocimiento cero y concluimos que los proveedores de participación y los equipos dedicados de conocimiento cero son más adecuados para satisfacer las necesidades emergentes del mercado de prueba de prueba que los mineros PoW.

Red de prueba y mercado de prueba

Las aplicaciones de conocimiento cero (ZK) requieren probadores para generar sus pruebas. Aunque actualmente está centralizado, la mayoría de las aplicaciones ZK tendrán su generación de prueba descentralizada. No es necesario confiar en el probador para producir el resultado correcto, ya que la prueba se puede verificar fácilmente. Sin embargo, hay varias razones por las que las aplicaciones buscan pruebas descentralizadas:

1. Vigencia: varios certificadores garantizan que el protocolo funcione de manera confiable y no experimente tiempos de inactividad cuando algunos certificadores no están disponibles temporalmente.

2. Resistencia a la censura: tener más probadores mejora la resistencia a la censura, un pequeño grupo de probadores puede negarse a atestiguar ciertos tipos de transacciones.

3. Competencia: Un conjunto más grande de probadores puede aumentar la presión del mercado sobre los operadores para crear pruebas más rápidas y económicas.

Esto deja a las aplicaciones frente a una decisión de diseño: ¿deberían lanzar ellas mismas sus propias redes de prueba o subcontratar la responsabilidad a un mercado de prueba? La subcontratación de la generación de pruebas a mercados de pruebas en desarrollo como =nil; (es un nombre de proyecto), RiscZero y Marlin proporciona pruebas descentralizadas plug-and-play y permite a los desarrolladores de aplicaciones centrarse en su pila de otros componentes. De hecho, estos mercados son una extensión natural del argumento de la modularidad. Similar a un pedido compartido, un mercado de prueba es en realidad una red compartida de probadores. También maximizan la utilización del hardware al compartir probadores entre aplicaciones; los probadores se pueden reutilizar cuando una aplicación no necesita generar pruebas inmediatamente.

Sin embargo, los mercados de prueba también tienen algunos inconvenientes. La internalización del rol de probador puede mejorar la utilidad de los tokens nativos al permitir que los protocolos aprovechen sus propios tokens para el staking y los incentivos del probador. Esto también puede proporcionar una mayor soberanía a la aplicación en lugar de crear un punto externo de falla.

Una diferencia importante entre una red de prueba y un mercado de prueba es que en una red de prueba, por lo general, solo una solicitud de prueba a la vez debe ser satisfecha por un conjunto de probadores. Por ejemplo, en Validity Rollup, la red recibe una serie de transacciones, calcula pruebas de validez para demostrar que se ejecutaron correctamente y envía las pruebas a L1 (red de una capa), se selecciona una única prueba de validez de un conjunto descentralizado de generado por el probador.

Red de prueba descentralizada

A medida que el protocolo ZK se estabilice, muchos equipos descentralizarán gradualmente su infraestructura para mejorar la vida de la red y la resistencia a la censura. La introducción de múltiples probadores al protocolo agrega complejidad adicional a la red, en particular, el protocolo ahora debe decidir qué probador asignar a un cálculo en particular. Actualmente existen tres enfoques principales:

Selección basada en probador de equidad: El probador promete activos para participar en la red. En cada período de prueba, se selecciona aleatoriamente un probador, cuyo peso está determinado por el valor de sus tokens apostados, y se calcula la salida. Cuando se seleccionan, los probadores son compensados por generar pruebas. Las condiciones de penalización específicas y la selección del líder pueden variar para cada protocolo. Este modelo es similar al mecanismo PoS.

Prueba de minería: La tarea del probador es generar repetidamente ZKP hasta que se genere una prueba con un valor hash lo suficientemente raro. Hacerlo les da derecho a atestiguar en la próxima época y ganar la recompensa de la época, y el probador puede generar más ZKP con más probabilidades de ganar la época. Este tipo de prueba es muy similar a la minería PoW: requiere mucha energía y recursos de hardware; una diferencia clave con la minería tradicional es que en PoW, el cálculo de hash es solo un medio para un fin. Poder generar hashes SHA-256 en Bitcoin no tiene otro valor que aumentar la seguridad de la red. Sin embargo, en la prueba de minería, la red brinda incentivos para que los mineros aceleren la generación de ZKP, lo que en última instancia beneficia a la red. La prueba de minería fue iniciada por Aleo.

Carrera de prueba: Durante cada época, los probadores compiten para generar pruebas lo más rápido posible. El primero en generar una prueba será recompensado con un espacio. Este enfoque es susceptible a la dinámica de que el ganador se lo lleva todo. Si un solo operador puede generar pruebas más rápido que otros, entonces debería ganar cada época. La centralización se puede reducir distribuyendo recompensas de prueba a los primeros N operadores para generar pruebas válidas por primera vez, o introduciendo algo de aleatoriedad. Sin embargo, incluso en este caso, los operadores más rápidos aún pueden operar varias máquinas para obtener otros ingresos.

Otra técnica son las pruebas distribuidas. En este caso, en lugar de que un solo esquema obtenga el derecho a producir una prueba durante un período determinado, la tarea de generar la prueba se distribuye entre varias partes, que trabajan juntas para producir un solo resultado. Un ejemplo es la red de prueba federada, que divide una prueba en muchas declaraciones más pequeñas que se pueden probar individualmente, y luego prueba recursivamente una sola declaración en una estructura de árbol. Otro ejemplo es zkBridge, que propone un nuevo protocolo ZKP llamado deVirgo que puede distribuir pruebas fácilmente en varias máquinas y que ha sido implementado por Polyhedra. Las pruebas distribuidas son inherentemente más fáciles de descentralizar y pueden aumentar significativamente la velocidad a la que se generan las pruebas. Cada participante forma un clúster de computación y participa en pruebas de minería o competencia. Las recompensas se pueden distribuir de manera uniforme en función de su contribución al grupo, y las pruebas distribuidas son compatibles con cualquier modelo de selección de probadores.

**La elección de certificadores basados en acciones, la extracción de pruebas y las pruebas de competencia deben sopesarse en tres aspectos: requisitos de capital, requisitos de acumulación de hardware y optimización del certificador. **

Los modelos de probadores basados en participación requieren que los probadores apuesten capital, pero son menos críticos para acelerar la generación de pruebas, ya que los probadores no se seleccionan en función de su velocidad de prueba (aunque es más probable que los probadores más rápidos atraigan la delegación). La prueba de minería es más equilibrada, requiere una cierta cantidad de capital para acumular máquinas y pagar costos de energía para generar más pruebas. También fomenta la aceleración de ZKP, al igual que la minería de Bitcoin fomenta el hash SHA-256 acelerado. Demostrando que la competencia requiere un capital e infraestructura mínimos, un operador puede ejecutar una máquina hiperoptimizada para competir en cada espacio. A pesar de ser el enfoque más liviano, creemos que las pruebas de concurso enfrentan el mayor riesgo de centralización debido a su dinámica en la que el ganador se lo lleva todo. Las competencias de prueba (como la minería) también dan como resultado cálculos redundantes, pero brindan mejores garantías de vida, ya que no hay necesidad de preocuparse de que al probador le falte un espacio para ser elegido.

Otro beneficio del modelo basado en participación es que hay menos presión sobre los probadores para competir en el desempeño, lo que permite espacio para la cooperación entre los operadores. Las colaboraciones a menudo incluyen el intercambio de conocimientos, como la difusión de nuevas técnicas para acelerar la generación de pruebas o la instrucción de nuevos operadores sobre cómo comenzar a realizar pruebas. En contraste, las competencias de prueba son más parecidas a las búsquedas MEV (Maximize Ethereum Value), donde las entidades son más confidenciales y antagónicas para mantener una ventaja competitiva.

De estos tres factores, creemos que la necesidad de velocidad será la principal variable que afectará si una red puede descentralizar su conjunto de probadores. Los recursos de capital y hardware serán abundantes, sin embargo, cuanto más compitan los probadores por la velocidad, menos descentralizada será la red. Por otro lado, cuanto más se motiva la velocidad, mejor funcionará la red, en igualdad de condiciones. Si bien los impactos exactos pueden variar, Proof of Networks enfrenta las mismas compensaciones entre rendimiento y descentralización que las cadenas de bloques de capa 1.

**¿Qué modelo de prueba ganará? **

Esperamos que la mayoría de las redes de prueba empleen un modelo basado en participación que proporcione el mejor equilibrio entre incentivar el rendimiento y mantener la descentralización.

Las pruebas descentralizadas pueden no ser adecuadas para la mayoría de las acumulaciones de validez. Los modelos en los que cada probador da fe de una fracción de transacciones y luego las agrega recursivamente enfrentan restricciones de ancho de banda de red. La naturaleza secuencial de las transacciones agregadas también dificulta la secuenciación: se deben incluir pruebas de transacciones anteriores antes de que se puedan probar las transacciones posteriores. Si un probador no proporciona su prueba, la prueba final no se puede construir.

Fuera de Aleo y Ironfish, la minería ZK no será popular en las aplicaciones ZK. Consume energía y es innecesario para la mayoría de las aplicaciones. Las carreras de prueba también son impopulares, ya que conducen a efectos de centralización. Cuanto más priorice un protocolo el rendimiento sobre la descentralización, más atractivo será el modelo basado en la carrera. Sin embargo, la aceleración de software y hardware ZK accesible existente ya proporciona mejoras sustanciales en la velocidad. Esperamos que para la mayoría de las aplicaciones, la adopción de un modelo de carreras de pruebas para aumentar la velocidad de generación de pruebas solo traiga una pequeña mejora a la red, y esta mejora no vale la pena sacrificar la red por su descentralización (carreras de pruebas).

** MERCADO DE PRUEBA DE DISEÑO**

A medida que más y más aplicaciones adoptan la tecnología de conocimiento cero (ZK), muchos se dan cuenta de que preferirían subcontratar la infraestructura ZK a un mercado de prueba en lugar de manejarla internamente. A diferencia de una red de prueba que solo atiende a una sola aplicación, un mercado de prueba puede atender múltiples aplicaciones y satisfacer sus respectivas necesidades de prueba diferentes. Estos mercados tienen como objetivo ser de alto rendimiento, descentralizados y flexibles.

ALTO RENDIMIENTO: Las necesidades del mercado serán diversas. Por ejemplo, algunas pruebas requieren más cálculos que otras. Las pruebas que tardan más en generarse requerirán hardware dedicado y otras optimizaciones para acelerar las pruebas de conocimiento cero (ZKP), y el mercado también necesita proporcionar servicios de generación de pruebas rápidas para aplicaciones y usuarios dispuestos a pagar.

Descentralización: Similar a Proof Network, Proof Market y sus aplicaciones quieren que el mercado esté descentralizado. Las pruebas descentralizadas aumentan la vitalidad, la resistencia a la censura y la eficiencia del mercado.

Flexibilidad: En igualdad de condiciones, demuestra que el mercado quiere ser lo más flexible posible para satisfacer las necesidades de las diferentes aplicaciones. Un zkBridge conectado a Ethereum puede requerir una prueba de finalidad similar a Groth16 para proporcionar una verificación de prueba de prueba en cadena barata. Por el contrario, los modelos zkML (ML se refiere al aprendizaje automático) pueden preferir esquemas de prueba basados en Nova, que están optimizados para pruebas recursivas. La flexibilidad también se puede reflejar en el proceso de integración.El mercado puede proporcionar una zkVM (Zero-Knowledge Virtual Machine) para verificar cálculos verificables de programas escritos en lenguajes de alto nivel (como Rust), brindando a los desarrolladores una forma más fácil de integrar.

El diseño de mercados de prueba que sean eficientes, descentralizados y lo suficientemente flexibles para admitir varias aplicaciones de prueba de conocimiento cero (ZKP) es un área de investigación difícil y aún no explorada en profundidad. Resolver este problema requiere un incentivo cuidadoso y un diseño técnico. A continuación, compartimos algunas exploraciones iniciales de las primeras consideraciones y compensaciones en el diseño de prueba de mercado:

  • Mecanismo de incentivos y castigos
  • Mecanismo de emparejamiento
  • Circuitos personalizados vs máquina virtual de conocimiento cero (zkVM)
  • Pruebas de continuidad vs agregación
  • Heterogeneidad de hardware
  • Diversidad de operadores
  • Descuentos, derivados y tipos de órdenes
  • privacidad
  • Descentralización gradual y continua

Mecanismo de Incentivos y Castigos

**Los probadores deben tener incentivos y sanciones para mantener la integridad y el desempeño del mercado. **La forma más fácil de introducir incentivos es utilizar dinámicas de replanteo y penalización. Los operadores pueden recibir incentivos mediante ofertas de prueba de solicitud, y posiblemente incluso recompensados a través de la inflación de tokens.

** Se puede imponer una participación mínima para unirse a la red para evitar ataques falsos. **Los certificadores que presenten pruebas falsas pueden ser penalizados por tokens apostados. Un probador también puede ser penalizado si tarda demasiado en generar una prueba o si no genera ninguna prueba. Es probable que esta sanción sea proporcional a la oferta de la prueba: cuanto mayor sea la oferta, la prueba se retrasará (y, por lo tanto, cuanto más significativa desde el punto de vista económico), mayor será la sanción.

En los casos en que la sanción (en el nodo de prueba de participación, los verificadores/certificadores serán sancionados si violan las reglas de POS) es excesiva, se puede utilizar un sistema de reputación en su lugar. =nil; (este es el nombre de un proyecto) actualmente utiliza un sistema basado en la reputación para responsabilizar a los probadores, y es menos probable que los probadores con un historial de deshonestidad o desempeño deficiente sean igualados con ofertas por el motor de comparación.

Mecanismo de coincidencia

El mecanismo de emparejamiento es el problema de conectar la oferta y la demanda en el mercado. Diseñar un motor de coincidencia, es decir, las reglas que definen cómo se emparejan los probadores con las solicitudes de certificación, será una de las tareas más difíciles e importantes para los mercados, que se puede realizar a través de subastas o libros de pedidos.

Subasta: La subasta involucra a los certificados que pujan por las solicitudes de certificación para determinar qué certificador gana el derecho a generar certificaciones. El desafío con las subastas es que si la oferta ganadora no devuelve una prueba, la subasta debe volver a ejecutarse (no puede reclutar inmediatamente al segundo postor más alto para una prueba).

Libro de pedidos: El libro de pedidos requiere que las solicitudes presenten ofertas para comprar pruebas en una base de datos abierta; los probadores deben enviar solicitudes para vender pruebas. Las ofertas y demandas se pueden igualar si se cumplen dos requisitos: 1) el precio calculado de la oferta del acuerdo es superior al precio de venta del probador, y 2) el tiempo de entrega del probador es inferior al tiempo de solicitud del licitación. En otras palabras, las aplicaciones envían un cálculo al libro de pedidos y definen la recompensa máxima que están dispuestos a pagar y el tiempo máximo que están dispuestos a esperar para recibir el comprobante. Los probadores son elegibles para ser emparejados si envían su solicitud por un precio y tiempo por debajo de este requisito. Los libros de pedidos son más adecuados para casos de uso de baja latencia porque las ofertas del libro de pedidos se pueden completar al instante.

Prueba de que los mercados son multidimensionales, las aplicaciones deben solicitar cálculos dentro de ciertos horizontes de precios y tiempos. Las aplicaciones pueden tener una preferencia dinámica por la latencia de las pruebas, y el precio que están dispuestas a pagar por la generación de pruebas disminuye con el tiempo. Si bien los libros de pedidos son eficientes, se quedan cortos en la complejidad de reflejar las preferencias del usuario.

Otros modelos coincidentes pueden aprender de otros mercados descentralizados, por ejemplo, el mercado de almacenamiento descentralizado de Filecoin utiliza la negociación fuera de la cadena, y el mercado de computación en la nube descentralizada de Akash utiliza subastas inversas. En el mercado de Akash, los desarrolladores (llamados "inquilinos") envían tareas informáticas a la red y los proveedores de la nube ofertan por las cargas de trabajo. El inquilino puede entonces elegir qué oferta aceptar. Las subastas inversas son ideales para Akash porque la latencia de la carga de trabajo no es crítica y los inquilinos pueden seleccionar manualmente las ofertas que desean. Por el contrario, los mercados de prueba deben funcionar de forma rápida y automática, lo que convierte a las subastas inversas en un sistema de correspondencia subóptimo para la generación de pruebas.

El protocolo puede imponer restricciones sobre los tipos de ofertas que pueden aceptar ciertos probadores. Por ejemplo, se le puede prohibir a un probador con un puntaje de reputación insuficiente igualar ofertas grandes.

Los protocolos deben proteger contra los vectores de ataque que surgen de las pruebas sin permiso. En algunos casos, el probador puede realizar un ataque de retraso de prueba: al retrasar o no devolver la prueba, el probador puede exponer el protocolo o sus usuarios a ciertos ataques económicos. Si el ataque es muy rentable, es posible que las penalizaciones simbólicas o las penalizaciones de puntuación de reputación no disuadan a los probadores malintencionados. En el caso de retrasos en la certificación, la rotación de los derechos de generación de pruebas a nuevos certificados minimiza el tiempo de inactividad.

Circuitos personalizados frente a máquina virtual de conocimiento cero (zkVM)

Los mercados de prueba pueden proporcionar circuitos personalizados para cada aplicación, o pueden proporcionar una máquina virtual de conocimiento cero de propósito general. Los circuitos personalizados, si bien tienen una sobrecarga más alta en integración y costos financieros, pueden dar como resultado un mejor rendimiento para la aplicación. Los mercados de prueba, las aplicaciones o los desarrolladores externos pueden crear circuitos personalizados y, a cambio de brindar servicios, pueden obtener una parte de los ingresos de la red, como es el caso de =nil;.

Aunque más lentas, las máquinas virtuales de conocimiento cero (zkVM) RISC-V basadas en STARK como RiscZero permiten a los desarrolladores de aplicaciones escribir programas verificables en los lenguajes de alto nivel Rust o C++. zkVM puede admitir aceleradores para operaciones hostiles comunes de conocimiento cero, como hashing y adición de curvas elípticas para mejorar el rendimiento. Si bien los mercados de prueba con circuitos personalizados pueden requerir libros de pedidos separados, lo que lleva a la fragmentación y especialización de los probadores, zkVM puede usar un solo libro de pedidos para facilitar y priorizar el cálculo en zkVM.

Prueba única frente a prueba agregada

Una vez que se generan las pruebas, se deben retroalimentar a la aplicación. Para las aplicaciones en cadena, esto requiere una costosa verificación en cadena. Los mercados de pruebas pueden enviar una sola prueba a los desarrolladores, o pueden usar pruebas agregadas para convertir múltiples pruebas en una sola antes de devolverlas, distribuyendo el costo del gas entre ellas.

La agregación de pruebas introduce latencia adicional, las pruebas deben agregarse juntas, lo que requiere más cómputo, y se deben completar varias pruebas para agregar, lo que puede retrasar el proceso de agregación.

Demuestre que el mercado debe decidir cómo manejar la compensación entre latencia y costo. Las pruebas pueden devolver temperaturas rápidas a un costo más alto o agregadas a un costo más bajo. Anticipamos que el mercado de pruebas requerirá pruebas agregadas, pero el tiempo para agregarlas se puede acortar a medida que se escalan.

Heterogeneidad de hardware

Las pruebas para cálculos grandes son lentas. Entonces, ¿qué pasa cuando una aplicación desea generar rápidamente pruebas computacionalmente intensivas? Los probadores pueden usar hardware más potente, como FPGA y ASIC, para acelerar la generación de pruebas. Si bien esto es de gran ayuda para el rendimiento, el hardware dedicado puede obstaculizar la descentralización al limitar el conjunto de posibles operadores, lo que demuestra que los mercados deben dictar el hardware en el que se ejecutan sus operadores.

Block unicorn Nota: FPGA (Field Programmable Gate Array) es la abreviatura de Field Programmable Gate Array. Este es un tipo especial de hardware informático que se puede reprogramar para realizar tareas específicas de procesamiento de números. Esto los hace útiles en aplicaciones que necesitan realizar ciertos tipos de cómputo, como el cifrado o el procesamiento de imágenes.

ASIC (Circuito integrado específico de la aplicación) es la abreviatura de circuito integrado específico de la aplicación. Este hardware está diseñado para realizar una tarea específica y es muy eficiente para realizar esa tarea. Por ejemplo, los ASIC de minería de Bitcoin están diseñados específicamente para realizar las operaciones de hash involucradas en la minería de Bitcoin. Los ASIC suelen ser muy eficientes, pero la desventaja es que no son tan flexibles como los FPGA porque solo se pueden usar para realizar las tareas para las que fueron diseñados.

También existe un problema con la homogeneidad de los probadores: el mercado de pruebas tiene que decidir si todos los probadores utilizarán el mismo hardware o admitirán diferentes configuraciones. Si todos los probadores estuvieran usando hardware fácilmente disponible en igualdad de condiciones, sería más fácil para el mercado mantener la descentralización. Dada la naturaleza incipiente del hardware de conocimiento cero y la necesidad de rendimiento del mercado, esperamos que el mercado de pruebas siga siendo independiente del hardware, lo que permite a los operadores ejecutar la infraestructura que deseen. Sin embargo, se necesita más trabajo sobre el impacto de la diversidad de hardware de los probadores en la centralización de los probadores.

Diversidad de operadores

Los desarrolladores deben definir los requisitos para que los operadores ingresen y sigan siendo participantes activos del mercado, lo que afectará la diversidad de los operadores, incluido su tamaño y distribución geográfica. Algunas consideraciones a nivel de protocolo incluyen:

¿Los certificadores deben estar en la lista blanca o sin permiso? ¿Habrá un límite en el número de probadores que pueden participar? ¿Los probadores necesitan apostar tokens para unirse a la red? ¿Existen requisitos mínimos de hardware o rendimiento? ¿Habrá un límite a la cuota de mercado que puede tener un operador? Si es así, ¿cómo se aplica esta restricción?

Los mercados que buscan específicamente operadores de grado institucional pueden tener diferentes requisitos de entrada al mercado que los mercados que buscan participación minorista. Prueba de que el mercado debe definir cómo se ve una combinación de portadores saludable y usar eso como base para la investigación inversa.

Descuentos, Derivados y Tipos de Órdenes

En momentos de mayor o menor demanda, los precios del mercado de prueba pueden experimentar fluctuaciones de precios. Las fluctuaciones de precios generan incertidumbre, y las aplicaciones deben predecir los precios de mercado de prueba futuros para pasar estas tarifas a los usuarios finales: un protocolo no quiere cobrar a los usuarios solo $ 0.01 en tarifas de transacción y luego descubrir que las transacciones de prueba cuestan $ 0.10. Este es el mismo problema que enfrenta la segunda capa que debe transferir el precio de los datos de llamadas futuras (los datos contenidos en él, la facturación de Ethereum Gas y el Gas se determinará de acuerdo con el tamaño de los datos) a los usuarios. Se ha sugerido que la segunda capa podría usar futuros de espacio en bloque para resolver este problema: la segunda capa puede comprar espacio en bloque a un precio fijo por adelantado, al mismo tiempo que proporciona a los usuarios un precio más estable.

La misma necesidad existe en el mercado de pruebas. Los protocolos como la acumulación de validez pueden generar pruebas con una frecuencia fija. Si un resumen necesita generar pruebas cada hora durante un año, ¿puede enviar esta oferta de una sola vez, en lugar de tener que enviar una nueva oferta ad hoc, lo que podría volverse vulnerable a los aumentos de precios? Idealmente, pueden pedir por adelantado una prueba de competencia. Si es así, ¿deberían proporcionarse futuros de prueba dentro del protocolo, o debería permitirse que otros protocolos o proveedores centralizados crearan servicios encima de él?

¿Qué pasa con los descuentos por pedidos predecibles o de gran volumen? Si un protocolo genera mucha demanda en el mercado, ¿debe obtener un descuento o debe pagar el precio de mercado abierto?

privacidad

**Los mercados de prueba pueden proporcionar computación privada, aunque la generación de prueba subcontratada es difícil de hacer de forma privada. **La aplicación requiere un canal seguro para enviar información privada al probador que no es de confianza. Una vez recibido, el probador necesita una caja de arena computacional segura para generar la prueba sin revelar entradas privadas; los enclaves seguros son una dirección prometedora. De hecho, Marlin ha experimentado con la informática privada en Azure utilizando las GPU A100 de Nvidia a través de Secure Enclave (una tecnología de hardware que proporciona un entorno informático aislado para datos confidenciales).

Descentralización gradual y duradera

El mercado de pruebas necesita encontrar la mejor manera de descentralizarse gradualmente ¿Cómo debería ingresar al mercado el primer lote de probadores de terceros? ¿Cuáles son los pasos específicos para lograr la descentralización?

Los temas relacionados incluyen el mantenimiento de la descentralización. Un desafío que enfrenta el mercado de pruebas es la oferta hostil de los probadores. Un probador bien financiado puede optar por operar con una oferta por debajo del mercado, desplazar a otros operadores con pérdidas y luego escalar y aumentar los precios. Otra forma de oferta hostil es operar demasiados nodos mientras se oferta al precio de mercado, de modo que una selección aleatoria le otorga a este operador una parte desproporcionada de las solicitudes de prueba.

resumen

Además de las consideraciones anteriores, otras decisiones incluyen cómo se presentan las ofertas y si la generación de pruebas se puede distribuir entre varios probadores. En general, resulta que los mercados tienen un gran espacio de diseño que debe estudiarse cuidadosamente para construir mercados eficientes y descentralizados. Esperamos trabajar con grupos líderes en este campo para identificar los enfoques más prometedores.

Operar una infraestructura de conocimiento cero Hasta ahora, hemos analizado las consideraciones de diseño para construir una red de prueba descentralizada y un mercado de prueba. En esta sección, evaluaremos qué operadores son los más adecuados para participar en la red de prueba y compartiremos algunas ideas sobre el lado de la oferta de la generación de prueba de conocimiento cero.

** Mineros y Validadores **

**Hay dos tipos principales de proveedores de infraestructura de blockchain en la actualidad: mineros y validadores. ** Los mineros ejecutan nodos en redes de prueba de trabajo como Bitcoin. Estos mineros compiten para producir un hashrate suficientemente raro. Cuanto más poderosas sean sus computadoras, y cuantas más computadoras tengan, es más probable que encuentren hashes raros y ganen recompensas en bloque. Los primeros mineros de bitcoin comenzaron a minar en computadoras domésticas usando CPU, pero a medida que la red creció y las recompensas en bloque se volvieron más valiosas, los mineros comenzaron a especializarse en sus operaciones. Los nodos se agrupan para lograr economías de escala y las configuraciones de hardware se especializan con el tiempo. Hoy en día, los mineros se ejecutan casi exclusivamente en centros de datos cercanos a fuentes de energía barata, utilizando circuitos integrados específicos de aplicaciones (ASIC) de bitcoin.

**El surgimiento de la prueba de participación requiere un nuevo tipo de operador de nodo: el validador. **Los verificadores tienen un rol similar al de los mineros. Proponen bloques, realizan transiciones de estado y participan en el consenso. Sin embargo, no son como los mineros de Bitcoin, que generan tanto hashrate (poder de cómputo) como sea posible para aumentar las posibilidades de crear un bloque. En cambio, los validadores se seleccionan aleatoriamente para proponer bloques en función del valor de los activos que se les asignan. Este cambio elimina la necesidad de equipos que consumen mucha energía y hardware especializado en PoS, lo que permite que los operadores de nodos más distribuidos ejecuten validadores, y los validadores pueden incluso ejecutarse en la nube.

El cambio más sutil introducido por la Prueba de participación (PoS) es que convierte el negocio de la infraestructura de la cadena de bloques en un negocio de servicios. En la Prueba de trabajo (PoW), los mineros operan en el backend, apenas visibles para los usuarios e inversores (¿puede nombrar algunos mineros de bitcoin?). Solo tienen un cliente, y esa es la propia red. En Proof of Stake, los validadores (como Lido, Rocket) proporcionan la seguridad de la red apostando sus tokens como garantía, pero también tienen otro cliente: los apostadores. Los poseedores de tokens buscan operadores en los que puedan confiar para ejecutar la infraestructura de forma segura en su nombre, obteniendo recompensas de participación. Dado que los validadores obtienen ingresos acordes con el crecimiento de activos que pueden atraer, operan como una empresa de servicios. Los validadores marcaron, contrataron equipos de ventas y establecieron relaciones con personas e instituciones que podían apostar sus tokens a los validadores. Esto hace que el negocio del staking sea muy diferente del negocio de la minería. Esta importante diferencia entre los dos negocios es una de las razones por las que los mayores proveedores de infraestructura de prueba de trabajo y prueba de participación son empresas completamente diferentes.

Corporación de infraestructura ZK

Durante el año pasado, surgieron varias empresas que se especializan en la aceleración de hardware ZKP (Zero-Knowledge Proof). Algunas de estas empresas producen hardware para venderlo a los operadores; otras ejecutan el hardware ellas mismas, convirtiéndose en un nuevo tipo de proveedor de infraestructura. Las empresas de hardware ZK más conocidas actualmente incluyen Cysic, Ulvetanna e Ingonyama. Cysic planea construir ASIC (circuitos integrados específicos de la aplicación) que puedan acelerar las operaciones ZKP comunes, mientras mantienen el chip flexible para futuras innovaciones de software. Ulvetanna está construyendo clústeres FPGA (Field Programmable Gate Array) para atender aplicaciones que requieren capacidades de prueba particularmente poderosas. Ingonyama está trabajando en mejoras de algoritmos y construyendo una biblioteca CUDA para aceleración ZK, con planes para diseñar eventualmente un ASIC.

Block unicorn notes: Biblioteca CUDA: CUDA (Arquitectura de dispositivo unificado de computación) es una plataforma de computación paralela y una interfaz de programación de aplicaciones (API) desarrollada por NVIDIA Corporation para su unidad de procesamiento de gráficos (GPU). La biblioteca CUDA es un conjunto de programas precompilados basados en CUDA que pueden realizar operaciones paralelas en GPU NVIDIA para aumentar la velocidad de procesamiento. Por ejemplo, bibliotecas de funciones para álgebra lineal, transformadas de Fourier, generación de números aleatorios y más.

ASIC: ASIC es la abreviatura de Application-Specific Integrated Circuit, traducido al chino como "circuito integrado de aplicación específica". Es un circuito integrado diseñado para cumplir con los requisitos de aplicaciones específicas. A diferencia de un procesador de uso general (como una unidad central de procesamiento CPU) que puede realizar varias operaciones, un ASIC ha determinado las tareas específicas que realizará cuando se diseña. Como resultado, los ASIC suelen lograr un mayor rendimiento o una mayor eficiencia energética en las tareas para las que están diseñados.

¿Quién operará la infraestructura ZK? Creemos que las empresas a las que les va bien en la operación de la infraestructura ZK están determinadas principalmente por el modelo de incentivos del probador y los requisitos de rendimiento. El mercado se dividirá en empresas de participación y nuevos equipos nativos de ZK. Para las aplicaciones que requieren el probador de mayor rendimiento o una latencia extremadamente baja, el equipo nativo de ZK que pueda ganar la competencia de prueba será el dominado. Esperamos que estos casos extremos sean la excepción y no la norma. El resto del mercado estará dominado por el negocio de staking.

¿Por qué los mineros no son adecuados para operar la infraestructura ZK? Después de todo, las pruebas ZK, especialmente para circuitos grandes, tienen muchas similitudes con la minería. Requiere mucha energía y recursos informáticos, y puede requerir hardware especializado. Sin embargo, **no creemos que los mineros sean los primeros líderes en el espacio de prueba. **

**Primero, el hardware de prueba de trabajo (PoW) no se puede usar de manera eficiente para probar el trabajo. **Los ASIC de Bitcoin no se pueden reutilizar por definición. Las GPU que se usaban comúnmente para minar Ethereum antes de la fusión, como Nvidia Cmp Hx, se diseñaron específicamente para minar, lo que hace que tengan un desempeño deficiente en las cargas de trabajo de ZK. Específicamente, su ancho de banda de datos es débil, lo que hace que la paralelización que ofrecen las GPU no sea una ganancia real. Los mineros que deseen ingresar al negocio de prueba de prueba tendrán que acumular hardware listo para ZK desde cero.

**Además, las empresas mineras carecen de reconocimiento de marca y están en desventaja en las pruebas basadas en participación. **La mayor ventaja para los mineros es su acceso a energía barata, lo que les permite cobrar tarifas más bajas o participar de manera más rentable en el mercado de prueba de prueba, pero es poco probable que esto compense los desafíos que enfrentan.

**Finalmente, los mineros están acostumbrados a requisitos estáticos. **La minería de Bitcoin y Ethereum no ha requerido cambios frecuentes o significativos en sus funciones hash, ni estos operadores han tenido que realizar otras modificaciones en los protocolos (excluyendo fusiones) que afecten su configuración de minería. Por el contrario, las pruebas ZK requieren vigilancia contra los cambios en la tecnología de prueba, lo que puede afectar la configuración y optimización del hardware.

Un modelo de prueba basado en participación es una elección natural para las empresas validadoras. Los inversores individuales e institucionales en aplicaciones de conocimiento cero delegarán sus tokens a proveedores de infraestructura a cambio de recompensas. Un negocio de participación tiene un equipo existente, experiencia y relaciones que pueden atraer una gran cantidad de delegación de tokens. Incluso para los protocolos que no son compatibles con la prueba de participación delegada (PoS), muchas empresas de validación ofrecen servicios de validación de lista blanca para ejecutar la infraestructura en nombre de otras partes, una práctica común en Ethereum.

Los validadores no tienen acceso a electricidad barata como los mineros, lo que los hace inadecuados para las tareas que consumen más energía. Es probable que la configuración de hardware requerida para ejecutar un probador para la agregación de validez sea más compleja que la de un verificador normal, pero es probable que se ajuste a la infraestructura actual de la nube o del servidor dedicado del verificador. Pero al igual que los mineros, estas empresas no tienen experiencia interna en ZK y luchan por seguir siendo competitivas en la carrera de prueba de prueba. Además de las pruebas basadas en staking, operar una infraestructura ZK tiene un modelo de negocio diferente al de operar un validador y no tiene un fuerte efecto de retroalimentación positiva con las operaciones de staking. Esperamos que los proveedores de infraestructura de ZK nativos dominen las tareas de prueba de alto rendimiento sin participación.

Resumir

Hoy en día, la mayoría de los probadores están a cargo de equipos que crean aplicaciones que los requieren. A medida que se lanzan y descentralizan más y más redes ZK, nuevos operadores ingresarán al mercado para satisfacer las necesidades de prueba. La identidad de estos operadores depende del modelo de selección de atestación y los requisitos de atestación impuestos por el protocolo particular.

Es muy probable que las empresas de infraestructura de participación y los operadores de infraestructura ZK nativos dominen este nuevo mercado.

Las pruebas descentralizadas son una nueva y emocionante frontera para la infraestructura de blockchain. Si usted es un proveedor de infraestructura o desarrollo de aplicaciones en el campo ZK, estamos muy contentos de escuchar sus opiniones y sugerencias.

Ver originales
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Recompensa
  • Comentar
  • Compartir
Comentar
0/400
Sin comentarios
  • Anclado
Opere con criptomonedas en cualquier momento y lugar
qrCode
Escanee para descargar la aplicación Gate
Comunidad
Español
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)