Arquitectura del Proveedor

Arquitectura general

El Aggregator, actuando como un proxy entre el calculador de ZKP y el contrato verificador en la cadena base, es un componente importante del Proveedor en el sistema ZK-PoW V2.0. Es responsable de:

• distribuir las tareas de prueba de ZKP y recibir los resultados de las tareas (pruebas de ZKP)

• gestionar las pruebas y enviarlas a la Cadena Base para obtener recompensas.

Según las tareas, el nuevo diseño del Aggregator de Lumoz se divide en tres submódulos: Proof Generator, Proof Manager y Proof Sender

• El Proof Generator es responsable de asignar las tareas de prueba al Proveedor (minero PoW), recibir los resultados de las tareas (pruebas de ZKP) y almacenar las pruebas de ZKP en la base de datos DB.

• El Proof Manager se encarga de administrar las pruebas de ZKP completadas y empaquetar las pruebas que están listas para ser enviadas a la cadena como tareas para el módulo de Envío de Pruebas.

• El módulo Proof Sender se encarga de la presentación en cadena de las pruebas de ZKP, enviándolas al contrato zkevm desplegado en la Cadena Base.

A continuación se presentan las introducciones de estos tres módulos:

Generador de pruebas

Rollup Chain agrupa un cierto número de transacciones en un lote, y luego varios lotes (según factores como la frecuencia de transacciones) se combinan en una secuencia. La secuencia se envía a la Base Chain, convirtiéndose en la unidad de envío de datos para cada operación en la cadena.

Durante el proceso, cada secuencia consta de uno o más lotes, y la prueba de conocimiento cero (ZKP) verifica la validez de la secuencia enviada. Por lo tanto, el lote es la unidad más pequeña de la tarea de prueba.

Dependiendo del número de batches incluidos en una sequence, las tareas de prueba requeridas varían de la siguiente manera:

• Si el número de batches es 1, el proceso de prueba involucra una BatchProofTaskseguida de una FinalProofTask, y las tareas se completan secuencialmente.

• Si la sequence contiene más de 1batch, el proceso de prueba implica múltiples BatchProofTasks, una AggregatorProofTask y una 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 Prueba de Trabajo (PoW), nuestro objetivo es generar pruebas de manera concurrente. Esto se logra en dos aspectos:

• La generación de pruebas para diferentes sequences se puede realizar de forma concurrente, ya que no hay dependencia contextual ni de estado.

• Dentro de la misma sequence, se pueden ejecutar múltiples BatchProofTasks de manera concurrente.

Este enfoque utiliza los recursos computacionales de los Provers de manera más eficiente, lo que resulta en una generación de pruebas más eficiente.

Administrador de pruebas

Este módulo es principalmente responsable de gestionar las pruebas de ZKP (Prueba de Conocimiento Cero) y controlar su verificación en la cadena de bloques. Está compuesto por tres módulos principales:

• submitPendingProof: Este módulo se ejecuta solo una vez cuando el Aggregator comienza. Su propósito es completar el envío de las pruebas de ZKP incompletas del servicio anterior del Aggregator. Esto maneja la situación en la que se ha enviado proofHash, pero otros mineros ya han enviado sus proofs. Para obtener más información sobre proofHash, consulte el módulo Proof sender.

• tryFetchProofToSend: Este módulo se ejecuta como una corutina y agrega la última prueba de ZKP generada, junto con su correspondiente sequence no verificada, a la memoria caché del Proof Sender, esperando su envío a la cadena de bloques.

• processResend: Este módulo se ejecuta como una corutina y tiene como objetivo volver a enviar las sequences que no hayan sido verificadas con éxito dentro de una ventana de tiempo determinada. Su propósito es asegurar que las secuencias que exceden el tiempo de verificación sean reenviadas para su procesamiento en la cadena de bloques.

Proof sender

Opside ha propuesto lograr la descentralización del probador mediante Presentación en dos pasos de ZKP. Este algoritmo previene los ataques de adelantamiento en ZKP y permite que más mineros reciban recompensas, fomentando así la participación de más mineros y proporcionando una potencia de cálculo de ZKP estable y continua.

El siguiente diagrama ilustra cómo Proof Sender implementa la presentación en dos pasos utilizando tres cachés seguras y ordenadas por prioridad. Estas cachés se ordenan según la altura de inicio de las sequences, asegurando que cada vez que se recupera un elemento de estas cachés, corresponde a la altura más baja de la sequence. Además, los elementos en estas cachés se deduplican. Cuanto menor sea la altura de la secuencia correspondiente, mayor será la prioridad para el procesamiento.

• finalProofMsgCache: Almacena los mensajes finalProof enviados por el Proof Manager, indicando la finalización de las pruebas de ZKP.

• monitPHTxCache: Almacena las transacciones de proofHash que deben ser monitoreadas.

• ProofHashCache: Almacena los mensajes de proof para su presentación en la cadena (on-chain).

Después de que se lance el módulo Proof Sender, se inician tres coroutines para consumir datos de las tres cachés. El proceso simplificado es el siguiente:

1. La corutina 1 consume los mensajes finalProof de la caché finalProofMsgCache, calcula el proofHash y, si cumple las condiciones para su presentación en la cadena (dentro de la ventana T1), envía el proofHash a la cadena y agrega la transacción de proofHash a la caché monitPHTxCache.

2. La corutina 2 consume los mensajes de transacciones de proofHash de la caché monitPHTxCache. Si el proofHash cumple las condiciones para su presentación en la cadena dentro de la ventana T2, construye el mensaje de prueba y lo almacena en la caché ProofHashCache.

3. La corutina 3 consume los mensajes de prueba de la caché ProofHashCache y envía las pruebas a la cadena.

Comparado con el módulo anterior, esta estructura es más clara y ahorra en la sobrecarga de recursos.