Opside: Pioneros probadores descentralizados para ZK-Rollups de próxima generación

¿Por qué necesitamos probadores descentralizados?

Actualmente, hay varios ZK-Rollups ejecutándose en la red principal de Ethereum. Sin embargo, el diseño de ZK-Rollups descentralizados aún se encuentra en sus primeras etapas. Actualmente estamos enfocados en el tema de los secuenciadores descentralizados, pero la mayoría de la gente pasa por alto el hecho de que actualmente, la mayoría de los proyectos ZK-Rollup no han implementado probadores descentralizados.

Para ZK-Rollups, un probador centralizado sigue siendo seguro y no presenta los mismos problemas de censura que un secuenciador centralizado. Sin embargo, un probador centralizado también puede causar muchos problemas. En primer lugar, si solo hay un probador, la falla de un solo nodo puede hacer que todo el ZK-Rollup no presente su prueba de validez, lo que afecta la finalidad de las transacciones.

En segundo lugar, el costo de un probador centralizado es alto y no puede satisfacer la demanda computacional de ZK-Rollups masivos en el futuro.

Finalmente, desde una perspectiva económica, solo un probador centralizado disfruta de una parte de las ganancias, lo que, desde una perspectiva económica simbólica, es en realidad injusto.

Desafíos de los probadores descentralizados

Los probadores descentralizados pueden resolver de manera efectiva los problemas anteriores, pero también presentan algunos desafíos. Esta es una de las razones por las que varios esquemas zkEVM lanzados recientemente han adoptado un esquema de probador centralizado. Por ejemplo, la red principal beta de Polygon zkEVM se basa en un agregador confiable para enviar ZKP, y la era zkSync es similar en este sentido.

Desde una perspectiva técnica, cuando el contrato inteligente de un ZK-Rollup verifica el ZKP, necesita los datos de prueba originales. Esto puede desencadenar potencialmente varios comportamientos de ataque en cadena. Por ejemplo, cuando un probador determinado envía el ZKP calculado al contrato a nivel de cadena, necesita enviar una transacción L1. Cuando esta transacción se transmite al grupo de transacciones, los atacantes pueden ver los datos de prueba originales y pueden establecer una tarifa de gas más alta para enviar una transacción, siendo así los primeros en agruparse en un bloque y obtener recompensas de PoW.

Además, dado que los probadores compiten entre sí en función del poder computacional, no existe un mecanismo confiable de reconocimiento de identidad y también es difícil establecer un mecanismo de comunicación. Diferentes mineros pueden realizar trabajos duplicados, lo que resulta en un desperdicio de potencia computacional.

Envío de dos pasos de ZKP

Paso 1: Enviar hash

• Después de que un probador calcula un ZKP para una determinada secuencia, primero calcula el hash de (prueba/dirección) y envía el hash y la dirección al contrato inteligente a nivel de cadena. Aquí, la prueba es una prueba de conocimiento cero para una determinada secuencia, y la dirección es la dirección del probador.

  
  

• Suponiendo que el primer probador envía el hash del ZKP en el bloque T, se acepta hasta el bloque T+10 sin ningún límite. A partir del bloque T+11, los nuevos probadores ya no pueden enviar el hash.

  
  

Paso 2: Enviar ZKP

• Después del bloque T+11, cualquier probador puede enviar un ZKP. Siempre que un ZKP pase la verificación, se puede usar para verificar todos los hashes enviados. Los probadores validados reciben recompensas de PoW en función de la proporción de las cantidades apostadas por los mineros.

  
  

• Si ningún ZKP pasa la verificación antes del bloque T+20, todos los probadores que hayan enviado hashes serán eliminados. Luego, la secuencia se vuelve a abrir y se pueden enviar nuevos hashes, volviendo al Paso 1.

  
  

Aquí hay un ejemplo: supongamos que cada bloque tiene una recompensa de PoW de 128 IDE en la red Opside, y actualmente hay 64 espacios acumulativos disponibles. Por lo tanto, a cada secuencia acumulada se le asigna una recompensa PoW de 2 IDE. Si tres mineros, A, B y C, envían con éxito el ZKP correcto para una secuencia sucesiva, las participaciones mineras (IDE) de los tres mineros son 200K, 500K y 300K, respectivamente. Luego, A, B y C pueden ganar cada uno una recompensa PoW de 0.4 IDE, 1 IDE y 0.6 IDE, respectivamente.

La apuesta simbólica y el castigo del probador

Para evitar el comportamiento malicioso del probador, el probador debe registrarse con un contrato de sistema especial y apostar una cierta cantidad de tokens. Si el monto de la apuesta actual es menor que el umbral, el probador no puede enviar el hash y el ZKP. La recompensa por la presentación del ZKP por parte del probador se distribuirá en función de la proporción del monto de la apuesta, evitando que el probador envíe varios ZKP.

Si el probador comete las siguientes acciones, se aplicarán diferentes niveles de castigo:

• El probador envía un hash incorrecto.
• Para una determinada secuencia, si ningún ZKP correspondiente pasa la verificación, todos los probadores que hayan enviado hashes serán sancionados.
• El token perdido será quemado.

Para obtener más detalles y consideraciones sobre el mecanismo de envío de dos pasos del ZKP, se recomienda a los lectores que consulten los documentos oficiales de Opside. Los números específicos de la apuesta y el castigo del probador pueden cambiar en el futuro.

Varias consideraciones:

• ¿Por qué permitir que varios probadores envíen hashes? Si solo se recompensa al primer probador que envía un hash, es posible que otros probadores no tengan un incentivo para enviar una prueba después de que el primer probador envíe un hash. Si un atacante malintencionado demora mucho tiempo en enviar la prueba después de enviar un hash, puede ralentizar la verificación de toda la secuencia. Por lo tanto, es necesario permitir que varios probadores envíen hashes de forma independiente y simultánea para evitar el monopolio de la verificación ZKP por parte de un solo atacante.

  
  

• ¿Por qué hay una ventana de tiempo? Si alguien puede enviar una prueba inmediatamente después de enviar un hash, la prueba aún puede ser robada. Los atacantes pueden enviar inmediatamente un hash asociado con su dirección y luego enviar una prueba para obtener recompensas. Al establecer una ventana de tiempo, los probadores que han enviado hashes no tienen ningún incentivo para enviar pruebas dentro de la ventana, evitando así la posibilidad de competir.

  
  

• ¿Por qué la recompensa se asigna en función de la apuesta? Múltiples probadores pueden enviar hashes para la misma secuencia dentro de una ventana de tiempo. De hecho, los mineros pueden enviar múltiples hashes utilizando su prueba generada (solo necesita varias direcciones). Esto puede llevar a que la mayoría o incluso todas las recompensas de PoW sean tomadas por mineros. Para evitar este ataque, la recompensa por una secuencia se asignará en función de la proporción del monto de la apuesta del minero.

  
  

Resumen y Planificación

El algoritmo de envío de dos pasos para ZKP propuesto en esta publicación realiza la descentralización del probador mientras evita de manera efectiva los ataques de carrera y alienta a más mineros a proporcionar potencia computacional ZKP estable y continua. La versión inicial del algoritmo se lanzará en la red de prueba pre-alfa de Opside.

En el futuro, Opside también presentará ideas más innovadoras en el campo de la minería ZKP, como:

• Ajuste dinámico de la relación de asignación de recompensas entre PoS y PoW en función de la demanda y el suministro de potencia computacional ZKP en toda la red.
• Mecanismo de fijación de precios personalizado para lotes de Rollup según el tipo de ZK-Rollup, la cantidad de transacciones de Rollup y el uso de gas del Rollup.
• Subsidios para que los desarrolladores de aplicaciones generen ZKP para sus Rollups asociados para alentar a los mineros a proporcionar poder computacional.