La aleatoriedad es fundamental para garantizar resultados justos, impredecibles e imparciales en sistemas distribuidos, sin embargo, puede ser susceptible a la manipulación sin un diseño adecuado.
Tabla de contenido:
- Aleatoriedad verificable en Web3
- ¿Qué es la aleatoriedad ‘buena’ o ‘verificable’?
- Análisis del paradigma compromiso-revelación
+Imposibilidad y desplazamientos
+Vulnerabilidad en Pyth VRF
- Conclusión
En este artículo, analizamos la aleatoriedad verificable (Verifiable Randomness) en el contexto de Web3, explorando sus características, importancia y vulnerabilidades.
Aleatoriedad verificable en Web3
La aleatoriedad verificable on-chain (en cadena) es un recurso crucial en las aplicaciones Web3. Este es especialmente el caso de las loterías en línea, los juegos blockchain, la acuñación y generación de rasgos de NFTs, la selección de líderes, la asignación de recursos digitales y mucho más. Es el ingrediente que nivela el campo de juego para los participantes, de modo que nadie pueda predecir los resultados antes de que ocurran, especialmente operadores de nodos u otros participantes que podrían intentar obtener conocimientos asimétricos y ventajas.
El acceso a fuentes verificables de aleatoriedad también permite otros protocolos criptográficos, como cálculos multipartitos (multiparty computations) y pruebas de conocimiento cero (zero-knowledge proofs — ZKP). Estos protocolos tienen una variedad de aplicaciones propias, con usos que incluyen el aprendizaje automático para preservar la privacidad (privacy-preserving machine learning), la creación de Bridges — o puentes — ZK y la computación verificable (verifiable computing). La única pregunta ahora es: ¿Qué es la aleatoriedad verificable?
¿Qué es la aleatoriedad “buena” o “verificable”?
En nuestro blog anterior, afirmamos que la aleatoriedad verificable o ‘buena’, que conduce a la generación de un número verdaderamente aleatorio, es:
- Impredecible: nadie puede calcular el número con antelación.
- Imparcial: el número aleatorio no puede estar sesgado para hacer que números específicos tengan más probabilidades de aparecer que otros (por ejemplo, el número siempre es par o siempre impar).
- Verificable públicamente: Cualquiera puede verificar que el número aleatorio se genera correctamente.
En nuestro whitepaper sobre Función Aleatoria Verificable Distribuida (Distributed Verifiable Random Function — dVRF), analizamos que el protocolo de servicio de aleatoriedad Supra dVRF satisface las tres propiedades anteriores y, por lo tanto, proporciona una buena aleatoriedad. Ahora, la pregunta principal es:
¿Cómo identificar si un protocolo de servicio de aleatoriedad está generando aleatoriedad “buena” verificable o aleatoriedad “mala” (es decir, no verificable)?
En una serie de blogs, exploraremos cómo generar y consumir aleatoriedad verificable en el espacio Web3. Comenzando con la publicación, nos sumergiremos en los protocolos de servicios de aleatoriedad que utilizan esquemas de compromiso-revelación. Nos referimos al concepto más amplio de compromiso-revelación como el paradigma de compromiso-revelación (commit-reveal paradigm).
Análisis del Paradigma Compromiso-Revelación
Comencemos con el paradigma simple de compromiso-revelación para argumentar que es imposible obtener aleatoriedad insesgable en este paradigma. Más adelante, también exploraremos las mismas vulnerabilidades que causarán problemas en el paradigma de confirmación-revelación en el cual se implementan los contratos inteligentes.
En el paradigma simple de confirmación-revelación, el proveedor de aleatoriedad y el usuario se comprometen con valores aleatorios x y s utilizando una función hash H. Al intercambiar los compromisos, el proveedor y el usuario revelan x y s entre sí. Tanto el usuario como el proveedor verifican los valores revelados contra los compromisos. Si los compromisos se verifican, calculan la aleatoriedad rand=H(x, s). Ilustramos este paradigma a continuación:
Dado que el usuario recibe x del proveedor después de intercambiar los compromisos, el usuario puede calcular el resultado de forma preventiva. Este es una falla de diseño fundamental, ya que el usuario puede continuar/detener el protocolo en el Paso 4 si el resultado es favorable/desfavorable. Esto permitiría al usuario maximizar sus ganancias. El proveedor no puede completar la ejecución sin obtener s del usuario ya que s permanece secreto. Por tanto, el resultado puede estar sesgado.
Impossibility and Get Around
Es imposible lograr una aleatoriedad imparcial utilizando compromiso-revelación sin ninguna suposición confiable. Cleve demostró que dos partes no pueden generar aleatoriedad imparcial sin ninguna suposición. Esto se debe a que una de las partes siempre recibirá su resultado primero y luego decidirá abortar el protocolo si el resultado es desfavorable, similar al ataque mostrado anteriormente.
Sin embargo, en el espacio Web3, el usuario y el proveedor pueden acceder a contratos inteligentes. Los contratos inteligentes actúan como una parte confiable para realizar un cálculo correcto de los valores públicos. El servicio de aleatoriedad utiliza contratos inteligentes para generar aleatoriedad impredecible, insesgable y públicamente verificable.
Sin embargo, es más fácil decirlo que hacerlo, especialmente en el paradigma de compromiso-revelación. Mostramos que el servicio de aleatoriedad existente de PythVRF radica en este paradigma e implementa contratos inteligentes, pero no logran producir resultados aleatorios imparciales.
Vulnerabilidad en Pyth VRF
El protocolo PythVRF opera en el paradigma compromiso-revelación donde el proveedor se compromete inicialmente con una secuencia de valores aleatorios (x1, x2,…xN) en el Contrato Inteligente de Entropía (Entropy Smart Contract).
El usuario inicia una solicitud eligiendo un valor aleatorio s. El usuario se compromete a s como c y luego envía c al contrato inteligente (SC). El contrato inteligente almacena c y asigna un número de secuencia único — reqid (indicado como i en PythVRF), al usuario. El usuario envía reqid (identificador de solicitud) al proveedor a través de una solicitud HTTP y recibe Xreqid. El usuario revela (s, Xreqid) al Contrato Inteligente de Entropía (Entropy SC).
El contrato inteligente verifica Xreqid (w.r.t. de los compromisos almacenados) y c, y luego calcula la aleatoriedad rand. El protocolo PythVRF se puede visualizar a continuación:
Un usuario malintencionado ataca el protocolo precalculando rand=H(s, Xreqid) una vez que obtiene Xreqid del proveedor. Si el resultado es favorable, entonces el usuario continúa con el protocolo; de lo contrario, lo aborta. Esto permite al usuario maximizar sus posibilidades de ganar en un juego de lotería en línea donde se tiene en cuenta la aleatoriedad del usuario mientras se deciden los ganadores.
Con Supra, se utiliza un clan de nodos en lugar de un solo nodo. Como resultado, los nodos individuales no pueden afectar ni retener los resultados aleatorios, ya que ninguno de ellos puede anticipar el resultado de antemano. Un cliente no puede evitar que el resultado se cargue on-chain una vez que ha iniciado la solicitud de aleatoriedad.
Conclusión
Esta es la primera de una serie de publicaciones de blog sobre aleatoriedad verificable en cadena. En esta publicación, discutimos la imposibilidad de obtener un resultado imparcial en el paradigma compromiso-revelación simple. Luego, demostramos que incluso en presencia de contratos inteligentes existen protocolos que no logran proporcionar una aleatoriedad imparcial.
En las próximas publicaciones, discutiremos cómo capturar formalmente las propiedades de imprevisibilidad, imparcialidad y verificabilidad pública que son esenciales para la aleatoriedad on-chain. Después, profundizaremos en los enfoques basados en VRF y Beacon para lograr una aleatoriedad verificable on-chain.
Artículo original: https://supra.com/academy/an-analysis-of-verifiable-randomness-in-web3/
Traductor: Alan Rada (Supra Spartan)
Project Manager / Content Writer
X: https://twitter.com/Crypto_Dhragon
Portfolio: alanrada.contently.com
https://www.linkedin.com/in/alan-rada/
