Opside ZK-PoW Introducción  Opside es una plataforma descentralizada ZK-RaaS (ZK-Rollup as a Service) y una red líder para la minería ZKP (Zero-Knowledge Proof). ZK-RaaS proporciona un servicio de un solo clic para generar ZK-Rollups para cualquier persona. Opside ofrece una base de lanzamiento universal de ZK-Rollup, lo que permite a los desarrolladores implementar fácilmente diferentes tipos de ZK-Rollups en varias cadenas base.  Cadenas base: Ethereum/Opside chain/BNB chain/Polygon PoS y otras cadenas públicas.  Tipos de ZK-Rollup: zkSync, Polygon zkEVM, Scroll, StarkNet y otras variantes de ZK-Rollups.   En el diseño de Opside, los desarrolladores pueden implementar ZK-Rollups en estas diferentes cadenas base. A medida que la tecnología ZK-Rollup madure, puede haber cientos o incluso miles de ZK-Rollups en el futuro, lo que creará una demanda significativa de poder de cómputo ZKP. Opside utiliza el mecanismo ZK-PoW para incentivar a los mineros a proporcionar potencia de cálculo ZKP, proporcionando así una infraestructura de hardware completa para ZK-Rollups.  Arquitectura ZK-PoW V2.0  La arquitectura general de ZK-PoW V2.0 consta de varios componentes clave:    esta es la infraestructura en la nube proporcionada por Opside para el cálculo de ZKP. Se implementa en múltiples cadenas, incluidas Ethereum, BNB Chain, Polygon PoS y Opside Chain. La nube ZK-PoW es responsable de coordinar y administrar las tareas de cálculo de ZKP. Nube ZK-PoW:    estos son los nodos operados por mineros que contribuyen con su poder computacional para realizar cálculos ZKP. Los mineros pueden participar en la red ZK-PoW ejecutando un software especializado en su hardware de minería. Nodos mineros:    la nube ZK-PoW distribuye tareas de cálculo ZKP a los nodos mineros. La distribución se realiza de manera descentralizada para garantizar la equidad y la eficiencia. Las tareas de ZKP incluyen generar y verificar pruebas de conocimiento cero para varios ZK-Rollups. Distribución de tareas ZKP:    Los nodos mineros reciben tareas de cómputo ZKP y realizan los cálculos necesarios para generar las pruebas requeridas. Esto implica ejecutar algoritmos criptográficos y realizar cálculos complejos. Cómputo ZKP:    una vez que se completan los cálculos de ZKP, los nodos mineros envían las pruebas generadas a ZK-PoW Cloud para su verificación. La infraestructura en la nube verifica la corrección de las pruebas para garantizar su validez e integridad. Envío de pruebas y verificación:    los mineros reciben incentivos para participar en la red ZK-PoW al obtener recompensas por sus contribuciones computacionales. El sistema de recompensas está diseñado para motivar a los mineros y mantener la seguridad y estabilidad de la red. Mecanismo de incentivos:  En general, ZK-PoW V2.0 combina el poder de los recursos informáticos de los mineros con la infraestructura de la nube para proporcionar un cálculo ZKP eficiente y escalable para una amplia gama de ZK-Rollups.  El Agregador es un componente importante del Prover en el sistema ZK-PoW V2.0. Es responsable de distribuir las tareas de prueba ZKP, recibir los resultados de las tareas (pruebas ZKP), administrar las pruebas y enviarlas a la Cadena Base para obtener recompensas. En función de sus funciones, la nueva versión del Agregador se divide en tres submódulos: Generador de pruebas, Administrador de pruebas y Remitente de pruebas.   El módulo Proof Generator es responsable de asignar tareas de prueba al Prover (minero PoW), recibir los resultados de la tarea (pruebas ZKP) y almacenar las pruebas ZKP en la base de datos.  El Proof Manager está a cargo de administrar las pruebas ZKP completas y empaquetar las pruebas que están listas para enviarse en cadena como tareas para el módulo Proof Sender.  El módulo Proof Sender maneja el envío en cadena de pruebas ZKP al enviarlas al contrato zkEVM implementado en la cadena base.  A continuación se presentan las introducciones de estos tres módulos:  generador de prueba  Rollup Chain agrega una cierta cantidad de transacciones en un lote y luego varios lotes (según factores como la frecuencia de las transacciones) se combinan en una secuencia. Luego, la secuencia se envía a la cadena base, lo que la convierte en la unidad de envío de datos para cada operación en cadena. Cada secuencia consta de uno o más lotes, y la prueba ZKP verifica la validez de la secuencia enviada. Por lo tanto, el lote es la tarea de unidad de prueba más pequeña. Dependiendo de la cantidad de lotes incluidos en una secuencia, las tareas de prueba requeridas varían de la siguiente manera:  Si el número de lotes es 1, el proceso de prueba involucra BatchProofTask seguido de FinalProofTask, y las tareas se completan secuencialmente.  Si la secuencia contiene más de 1 lote, el proceso de prueba involucra múltiples BatchProofTasks, AggregatorProofTask y FinalProofTask, y las tareas se completan secuencialmente.  Para maximizar la eficiencia de la generación de pruebas y aumentar las recompensas mineras para los mineros de PoW, nuestro objetivo es generar pruebas al mismo tiempo. Esto se logra en dos aspectos:  La generación de pruebas para diferentes secuencias se puede realizar simultáneamente ya que no hay dependencia contextual o de estado.  Dentro de la misma secuencia, se pueden ejecutar varias BatchProofTasks al mismo tiempo.  Este enfoque utiliza los recursos computacionales de Provers de manera más eficiente, lo que da como resultado una generación de pruebas más eficiente.  administrador de pruebas  Este módulo es el principal responsable de administrar las pruebas ZKP y controlar su verificación en cadena. Consta de tres módulos principales:    : este módulo se ejecuta solo una vez cuando se inicia el Agregador. Su propósito es completar el envío de pruebas ZKP inconclusas del servicio Aggregator anterior. Esto maneja la situación en la que se ha enviado proofHash pero otros mineros ya han enviado sus pruebas. Para obtener más información sobre proofHash, consulte el módulo Proof Sender. submitPendingProof    : este módulo se ejecuta como una rutina y agrega la última prueba ZKP generada, junto con su correspondiente secuencia no verificada, a la memoria caché de Proof Sender, esperando el envío en cadena. tryFetchProofToSend    : este módulo se ejecuta como una rutina y tiene como objetivo volver a enviar secuencias que no se han verificado con éxito dentro de un período de tiempo determinado. Su propósito es garantizar que las secuencias que excedan el tiempo de verificación se vuelvan a enviar para su procesamiento en cadena. processResend  remitente de prueba    ha propuesto un algoritmo de envío ZKP de dos pasos para lograr la descentralización del probador. Este algoritmo evita los ataques frontales de ZKP y permite que más mineros reciban recompensas, lo que alienta a más mineros a participar y proporciona un poder de cómputo ZKP estable y continuo. Opside    : al producir una prueba de PoW para una secuencia específica (denominada prueba), el probador primero calcula el hash de "prueba/dirección" y lo envía al contrato. Si no se ha enviado antes un proofHash para esa secuencia, se abre una ventana de tiempo de envío de proofHash, T1. Los mineros son elegibles para enviar la secuencia dentro de los bloques T1, y la prueba solo se puede enviar después de los bloques T1. Paso 1    : después de los bloques T1, se abre la ventana de envío de pruebas para los bloques T2. Si ninguna de las pruebas enviadas pasa la verificación dentro de los bloques T2, todos los mineros que enviaron previamente proofHash serán penalizados. Si proofHash se envía con éxito dentro de la ventana de tiempo T1 pero la prueba no se puede enviar con éxito dentro de la ventana de tiempo T2, y otros mineros envían con éxito sus pruebas dentro de la ventana T2, el probador aún puede continuar enviando esa prueba. En otros escenarios, se reinicia el proceso de envío de dos pasos. Paso 2  El siguiente diagrama ilustra cómo Proof Sender implementa el envío de dos pasos utilizando tres cachés ordenados por prioridad y seguros para subprocesos. Estos cachés se clasifican en función de la altura inicial de las secuencias, lo que garantiza que cada vez que se recupera un elemento de estos cachés, corresponde a la altura de secuencia más baja. Además, los elementos de estos cachés están deduplicados. Cuanto menor sea la altura de la secuencia correspondiente, mayor será la prioridad para el procesamiento.  finalProofMsgCache: almacena los mensajes de finalProof enviados por Proof Manager, que indican la finalización de las pruebas ZKP.  monitPHTxCache: Almacena las transacciones de proofHash para ser monitoreadas.  ProofHashCache: almacena los mensajes de prueba para el envío en cadena.   Después de que se inicia el módulo Proof Sender, se inician tres rutinas para consumir datos de los tres cachés. El proceso simplificado es el siguiente:  Coroutine 1 consume los mensajes finalProof de finalProofMsgCache, calcula el proofHash y, si cumple las condiciones para el envío en cadena (dentro de la ventana T1), envía el proofHash a la cadena y agrega la transacción proofHash al monitPHTxCache.  Coroutine 2 consume los mensajes de transacción de proofHash de monitPHTxCache. Si proofHash cumple las condiciones para el envío en cadena dentro de la ventana T2, construye el mensaje de prueba y lo almacena en ProofHashCache.  Coroutine 3 consume los mensajes de prueba de ProofHashCache y envía las pruebas a la cadena.  En comparación con el módulo anterior, esta estructura es más clara y ahorra gastos generales de recursos.  Resumen  Comparación con la versión 1.0  La versión 2.0 divide el servicio original en tres submódulos, cada uno responsable de la generación de pruebas, la gestión de pruebas y el envío de pruebas, lo que da como resultado una estructura más clara, un menor acoplamiento y una mayor solidez.  El módulo de generación de prueba, Proof Generator, agregó el parámetro startBatch en comparación con la versión anterior, lo que facilita que los nuevos mineros se pongan al día con el progreso de la minería.  El módulo de gestión de pruebas, Proof Manager, se ha mejorado en comparación con la versión anterior. Reenvía rápidamente las pruebas en caso de reinicio del servicio minero u otras razones por las que falla el envío de pruebas, lo que garantiza los intereses de los mineros. El mecanismo de reenvío no solo aborda los casos de fallas en el envío de pruebas, sino que también maneja todos los casos de fallas en el envío de pruebas o no envío, lo que garantiza la seguridad de la cadena de resumen.  El módulo de envío de pruebas, Proof Sender, implementa un envío de transacciones de dos pasos utilizando tres cachés de prioridad seguros para subprocesos. Reduce el uso de bloqueos globales en comparación con versiones anteriores, lo que garantiza que las pruebas con alturas más bajas se envíen con prontitud y proteja los intereses de los mineros. Además, el flujo de servicio general es más claro, con un recuento reducido de subprocesos y un consumo de recursos reducido durante la ejecución del programa.  Resultados de las pruebas de estrés:  En la versión 2.0, utilizando 10 máquinas con 64 núcleos cada una, se completaron 566 pruebas por lotes en 7 horas, 38 minutos y 40 segundos, con un tiempo promedio de 48,62 segundos por prueba. En un escenario de varios mineros, en comparación con la versión 1.0, la eficiencia de la generación de prueba zk en la versión 2.0 mejoró en un 50 % en general.  En conclusión, Opside ZK-PoW V2.0 ha optimizado el proceso de múltiples mineros que participan en los cálculos de ZKP, mejorando la utilización del hardware, mejorando la disponibilidad del servicio y siendo más amigable para los mineros. Es importante destacar que, en un escenario de múltiples mineros, el tiempo de cálculo para ZKP se ha reducido a menos de un minuto, acelerando significativamente el tiempo de confirmación de las transacciones ZK-Rollup.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Get Free Unlimited IP Geo Data With IPinfo Lite

Opside ZK-PoW V2.0: una red de prueba descentralizada de múltiples cadenas y múltiples acumulaciones

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Telegram: el puente de Crypto Island hacia el continente

Una breve introducción a la teoría del cerebro de Boltzmann

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Telegram: el puente de Crypto Island hacia el continente

Una breve introducción a la teoría del cerebro de Boltzmann

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps