introducción

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Al igual que con el concepto de cifrado absolutamente fuerte de la criptografía, los protocolos reales de "Baliza aleatoria públicamente verificable" (en adelante PVRB) solo intentan acercarse lo más posible al esquema ideal, porque en las redes reales no es aplicable en su forma pura: es necesario acordar estrictamente un bit, debe haber muchas rondas y todos los mensajes deben ser perfectamente rápidos y siempre entregados. Por supuesto, este no es el caso en las redes reales. Por lo tanto, al diseñar PVRB para tareas específicas en las cadenas de bloques modernas, además de la imposibilidad de controlar la aleatoriedad y la fuerza criptográfica resultantes, surgen muchos más problemas puramente arquitectónicos y técnicos.

Para PVRB, la cadena de bloques en sí es esencialmente un medio de comunicación en el que mensajes = transacciones. Esto le permite abstraerse parcialmente de los problemas de la red, la falta de entrega de mensajes, los problemas con el middleware; todos estos riesgos los asume la red descentralizada, y su principal valor para PVRB es la imposibilidad de revocar o corromper una transacción ya enviada; No permitir que los participantes se nieguen a participar en el protocolo, a menos que hayan llevado a cabo un ataque exitoso al consenso. Este nivel de seguridad es aceptable, por lo que PVRB debería ser resistente a la colusión de los participantes exactamente en la misma medida que la cadena blockchain principal. Además, esto sugiere que el PVRB debe ser parte del consenso si la red está de acuerdo con la cadena de bloques principal, incluso si también está de acuerdo con la única aleatoria resultante justa. O bien, PVRB es simplemente un protocolo independiente implementado mediante un contrato inteligente que funciona de forma asincrónica con respecto a la cadena de bloques y los bloques. Ambos métodos tienen sus ventajas y desventajas, y la elección entre ellos no es nada trivial.

Dos formas de implementar PVRB

Describamos con más detalle dos opciones para implementar PVRB: la versión independiente, que funciona mediante un contrato inteligente independiente de la cadena de bloques, y la versión integrada por consenso, integrada en el protocolo, según la cual la red acuerda la cadena de bloques y el transacciones a incluir. En todos los casos, me refiero a los motores blockchain populares: Ethereum, EOS y todos aquellos similares en la forma en que alojan y procesan contratos inteligentes.

Contrato independiente

En esta versión, PVRB es un contrato inteligente que acepta transacciones de productores aleatorios (en adelante, RP), las procesa, combina los resultados y, como resultado, llega a un valor determinado que cualquier usuario puede recibir de este contrato. Este valor no puede almacenarse directamente en el contrato, sino que puede representarse únicamente mediante datos de los que se puede obtener de forma determinista uno y sólo un valor del resultado aleatorio. En este esquema, los RP son usuarios de la cadena de bloques y cualquiera puede participar en el proceso de generación.

La opción con contrato independiente es buena:

• portabilidad (los contratos se pueden arrastrar de blockchain a blockchain)
• facilidad de implementación y prueba (los contratos son fáciles de redactar y probar)
• conveniencia en la implementación de esquemas económicos (es fácil crear su propio token, cuya lógica sirve a los propósitos de PVRB)
• posibilidad de lanzamiento en blockchains que ya funcionan

También tiene desventajas:

• fuertes limitaciones en recursos informáticos, volumen de transacciones y almacenamiento (en otras palabras, cpu/mem/io)
• restricciones en las operaciones dentro del contrato (no todas las instrucciones están disponibles, es difícil conectar bibliotecas externas)
• incapacidad para organizar los mensajes más rápido de lo que se incluyen las transacciones en la cadena de bloques

Esta opción es adecuada para implementar un PVRB que debe ejecutarse en una red existente, no contiene criptografía compleja y no requiere una gran cantidad de interacciones.

Integrado por consenso

En esta versión, PVRB se implementa en el código del nodo blockchain, integrado o ejecutándose en paralelo con el intercambio de mensajes entre nodos blockchain. Los resultados del protocolo se escriben directamente en los bloques producidos y los mensajes de protocolo se envían a través de la red p2p entre nodos. Dado que el protocolo da como resultado números que deben escribirse en bloques, la red debe llegar a un consenso sobre ellos. Esto significa que los mensajes PVRB, al igual que las transacciones, deben ser validados por nodos e incluidos en bloques para que cualquier participante de la red pueda validar el cumplimiento del protocolo PVRB. Esto nos lleva automáticamente a la solución obvia: si la red llega a un consenso sobre un bloque y las transacciones en él, entonces PVRB debería ser parte del consenso y no un protocolo independiente. De lo contrario, es posible que un bloque sea válido desde el punto de vista del consenso, pero no se siga el protocolo PVRB y, desde el punto de vista PVRB, el bloque no pueda aceptarse. Entonces, si se elige la opción “integrada por el consenso”, la PVRB se convierte en una parte importante del consenso.

Al describir las implementaciones de PVRB a nivel de consenso de red, no se pueden evitar de ninguna manera cuestiones de finalidad. La finalidad es un mecanismo utilizado en consensos deterministas que compromete un bloque (y la cadena que conduce a él) que es definitivo y nunca será desechado, incluso si se produce una bifurcación paralela. Por ejemplo, en Bitcoin no existe tal mecanismo: si publica una cadena de mayor complejidad, reemplazará a otra menos compleja, independientemente de la longitud de las cadenas. Y en EOS, por ejemplo, los definitivos son los llamados Últimos Bloques Irreversibles, que aparecen en promedio cada 432 bloques (12*21 + 12*15, prevoto + precompromiso). Este proceso esencialmente está esperando las firmas de 2/3 de los productores de bloques (en lo sucesivo, BP). Cuando aparecen bifurcaciones que son más antiguas que la última LIB, simplemente se descartan. Este mecanismo permite garantizar que la transacción se incluye en la cadena de bloques y nunca será revertida, sin importar los recursos que tenga el atacante. Además, los bloques finales son bloques firmados por 2/3 de BP en Hyperledger, Tendermint y otros consensos basados ​​en pBFT. Además, tiene sentido hacer que un protocolo para garantizar la finalidad sea un complemento al consenso, ya que puede funcionar de forma asincrónica con la producción y publicación de bloques. Aquí hay uno bueno. artículo sobre la finalidad en Ethereum.

La finalidad es extremadamente importante para los usuarios, quienes sin ella pueden ser víctimas de un ataque de “doble gasto”, donde BP los “retiene” y los publica después de que la red haya “visto” una buena transacción. Si no hay una finalidad, entonces la bifurcación publicada reemplaza el bloque de una transacción "buena" por otra, de una bifurcación "mala", en la que los mismos fondos se transfieren a la dirección del atacante. En el caso de PVRB, los requisitos de finalidad son aún más estrictos, ya que construir bifurcaciones para PVRB significa la oportunidad para que un atacante prepare varias opciones aleatorias para publicar la más rentable, y limitar el tiempo de un posible ataque es una buena solución.

Por lo tanto, la mejor opción es combinar PVRB y finalidad en un protocolo; luego, el bloque finalizado = aleatorio finalizado, y esto es exactamente lo que necesitábamos obtener. Ahora los jugadores recibirán un juego aleatorio garantizado en N segundos y pueden estar seguros de que es imposible revertirlo o reproducirlo nuevamente.

La opción integrada por consenso es buena:

• la posibilidad de implementación asíncrona en relación con la producción de bloques: los bloques se producen como de costumbre, pero en paralelo puede funcionar el protocolo PVRB, que no produce aleatoriedad para cada bloque
• la capacidad de implementar incluso criptografía pesada, sin las restricciones impuestas a los contratos inteligentes
• la capacidad de organizar el intercambio de mensajes más rápido que las transacciones se incluyen en la cadena de bloques, por ejemplo, parte del protocolo puede funcionar entre nodos sin distribuir mensajes a través de la red.

También tiene desventajas:

• Dificultades en las pruebas y el desarrollo: tendrá que emular errores de red, nodos faltantes y bifurcaciones duras de la red.
• Los errores de implementación requieren un hardfork de red

Ambos métodos de implementación de PVRB tienen derecho a la vida, pero la implementación de contratos inteligentes en las cadenas de bloques modernas todavía tiene recursos informáticos bastante limitados, y cualquier transición a una criptografía seria a menudo es simplemente imposible. Y necesitaremos una criptografía seria, como se demostrará a continuación. Aunque este problema es claramente temporal, se necesita una criptografía seria en los contratos para resolver muchos problemas, y está apareciendo gradualmente (por ejemplo, contratos de sistema para zkSNARK en Ethereum).

Blockchain, que proporciona un canal de mensajería de protocolo transparente y confiable, no lo hace de forma gratuita. Cualquier protocolo descentralizado debe tener en cuenta la posibilidad de un ataque Sybil; cualquier acción puede ser realizada por fuerzas concertadas de múltiples cuentas, por lo tanto, al diseñar, es necesario tener en cuenta la capacidad de los atacantes para crear un número arbitrario de protocolos. participantes que actúan en connivencia.

PVRB y variables de bloque.

No mentí cuando dije que nadie ha implementado todavía un buen PVRB, probado por muchas aplicaciones de juegos de azar, en blockchains. Entonces, ¿de dónde provienen tantas aplicaciones de juegos de azar en Ethereum y EOS? Esto me sorprende tanto como a ti, ¿de dónde sacaron tantos randoms “persistentes” en un entorno completamente determinista?

La forma favorita de conseguir aleatoriedad en la cadena de bloques es tomar algún tipo de información "impredecible" del bloque y crear una aleatoria basada en ella, simplemente aplicando hash a uno o más valores. Buen artículo sobre los problemas de tales esquemas. aquí. Puede tomar cualquiera de los valores "impredecibles" del bloque, por ejemplo, el hash del bloque, el número de transacciones, la complejidad de la red y otros valores desconocidos de antemano. Luego haz un hash de ellos, uno o más, y, en teoría, deberías obtener un resultado aleatorio real. Incluso puede agregar al documento blanco que su esquema es "seguro poscuántico" (ya que existen funciones hash a prueba de cuántica :)).

Pero, lamentablemente, incluso los hashes seguros poscuánticos no son suficientes. El secreto está en los requisitos para PVRB, déjame recordartelos del artículo anterior:

1. El resultado debe tener una distribución demostrablemente uniforme, es decir, basarse en una criptografía demostrablemente sólida.
2. No es posible controlar ninguno de los bits del resultado. En consecuencia, el resultado no se puede predecir de antemano.
3. No se puede sabotear el protocolo de generación no participando en el protocolo o sobrecargando la red con mensajes de ataque.
4. Todo lo anterior debe ser resistente a la colusión de un número permitido de participantes deshonestos en el protocolo (por ejemplo, 1/3 de los participantes).

En este caso, solo se cumple el requisito 1 y no se cumple el requisito 2. Al combinar valores impredecibles del bloque, obtendremos una distribución uniforme y buenos resultados aleatorios. Pero BP al menos tiene la opción de “publicar el bloque o no”. Por lo tanto, BP puede elegir al menos entre DOS opciones aleatorias: “la suya” y la que resultará si alguien más hace el bloque. BP puede "espiar" de antemano qué sucederá si publica un bloque y simplemente decide hacerlo o no. Así, cuando juega, por ejemplo, en la ruleta “par-impar” o “rojo/negro”, puede publicar un bloque sólo si ve una ganancia. Esto también hace que la estrategia de utilizar, por ejemplo, un hash de bloque "del futuro" sea inviable. En este caso, dicen que “se utilizará aleatorio, que se obtiene haciendo un hash de los datos actuales y el hash de un bloque futuro con una altura de, por ejemplo, N + 42, donde N es la altura del bloque actual. Esto fortalece un poco el esquema, pero aún permite a BP, aunque en el futuro, elegir si mantener el bloque o publicarlo.

El software BP en este caso se vuelve más complicado, pero no mucho. Simplemente, al validar e incluir una transacción en un bloque, hay una verificación rápida para ver si habrá una ganancia y, posiblemente, la selección de los parámetros de una transacción para obtener una alta probabilidad de ganar. Al mismo tiempo, es casi imposible atrapar a un BP inteligente para tales manipulaciones; cada vez puedes usar nuevas direcciones y ganar poco a poco sin despertar sospechas.

Por tanto, los métodos que utilizan información del bloque no son adecuados como implementación universal de PVRB. En una versión limitada, con restricciones en el tamaño de las apuestas, restricciones en el número de jugadores y/o registro KYC (para evitar que un jugador use varias direcciones), estos esquemas pueden funcionar para juegos pequeños, pero nada más.

PVRB y compromiso-revelación.

Bien, gracias al hash y al menos a la relativa imprevisibilidad del hash del bloque y otras variables. Si resuelve el problema de los mineros adelantados, debería conseguir algo más adecuado. Agreguemos usuarios a este esquema; dejemos que también influyan en la aleatoriedad: cualquier empleado de soporte técnico le dirá que lo más aleatorio en los sistemas de TI son las acciones de los usuarios :)

Un esquema ingenuo en el que los usuarios simplemente envían números aleatorios y el resultado se calcula como, por ejemplo, un hash de su suma, no es adecuado. En este caso, el último jugador puede, eligiendo su propio azar, controlar cuál será el resultado. Es por eso que se utiliza el patrón de confirmación-revelación muy utilizado. Los participantes primero envían hashes desde sus randoms (confirmaciones) y luego abren los randoms ellos mismos (revelaciones). La fase de "revelación" comienza solo después de que se hayan recopilado las confirmaciones necesarias, de modo que los participantes puedan enviar exactamente el hash aleatorio desde el que enviaron anteriormente. Ahora juntemos todo esto con los parámetros de un bloque, y mejor que uno tomado del futuro (la aleatoriedad solo se puede encontrar en uno de los bloques futuros), y listo, ¡la aleatoriedad está lista! Ahora cualquier jugador influye en la aleatoriedad resultante y puede "vencer" al BP malicioso anulándolo con su propia aleatoriedad, desconocida de antemano... También puede agregar protección contra el sabotaje del protocolo al no abrirlo en la etapa de revelación, simplemente al exigir que se adjunte una cierta cantidad a la transacción al momento de comprometerse: un depósito de seguridad, que será devuelto solo durante el procedimiento de revelación. En este caso, comprometerse y no revelar no será rentable.

Fue un buen intento y este tipo de esquemas también existen en las DApps de juegos, pero, por desgracia, esto tampoco es suficiente. Ahora no sólo el minero, sino también cualquier participante en el protocolo puede influir en el resultado. Todavía es posible controlar el valor en sí, con menos variabilidad y con un costo, pero, como en el caso del minero, si los resultados del sorteo son más valiosos que la tarifa por participar en el protocolo PVRB, entonces el azar -El productor (RP) puede decidir si revelar y aún puede elegir entre al menos dos opciones aleatorias.
Pero ahora es posible castigar a quienes cometen y no revelan, y este esquema será útil. Su simplicidad es una gran ventaja: los protocolos más serios requieren cálculos mucho más potentes.

PVRB y firmas deterministas.

Hay otra forma de obligar al RP a proporcionar un número pseudoaleatorio en el que no puede influir si se le proporciona una "preimagen": esta es una firma determinista. Esta firma es, por ejemplo, RSA y no ECS. Si RP tiene un par de claves: RSA y ECC, y firma un determinado valor con su clave privada, entonces en el caso de RSA obtendrá UNA Y SÓLO UNA firma, y ​​en el caso de ECS puede generar cualquier número de diferentes firmas válidas. Esto se debe a que al crear una firma ECS se utiliza un número aleatorio, elegido por el firmante, y puede ser elegido de cualquier forma, dándole al firmante la oportunidad de elegir una de varias firmas. En el caso de RSA: “un valor de entrada” + “un par de claves” = “una firma”. Es imposible predecir qué firma obtendrá otro RP, por lo que se puede organizar un PVRB con firmas deterministas combinando las firmas RSA de varios participantes que firmaron el mismo valor. Por ejemplo, el azar anterior. Este esquema ahorra muchos recursos, porque las firmas son a la vez una confirmación del comportamiento correcto según el protocolo y una fuente de aleatoriedad.

Sin embargo, incluso con firmas deterministas, el esquema sigue siendo vulnerable al problema del “último actor”. El último participante aún puede decidir si publicar la firma o no, controlando así el resultado. Puede modificar el esquema, agregarle hash de bloque, hacer rondas para que el resultado no se pueda predecir de antemano, pero todas estas técnicas, incluso teniendo en cuenta muchas modificaciones, aún dejan sin resolver el problema de la influencia de un participante en el colectivo. resulta en un entorno poco confiable y sólo puede funcionar bajo limitaciones económicas y de tiempo. Además, el tamaño de las claves RSA (1024 y 2048 bits) es bastante grande y el tamaño de las transacciones blockchain es un parámetro extremadamente importante. Al parecer no existe una forma sencilla de solucionar el problema, sigamos adelante.

PVRB y esquemas de intercambio secreto

En criptografía, existen esquemas que pueden permitir que la red acuerde un solo valor PVRB, mientras que dichos esquemas son resistentes a cualquier acción maliciosa de algunos participantes. Un protocolo útil con el que vale la pena familiarizarse es el plan secreto para compartir de Shamir. Sirve para dividir un secreto (por ejemplo, una clave secreta) en varias partes y distribuir estas partes a N participantes. El secreto se distribuye de tal manera que M partes de N son suficientes para recuperarlo, y estas pueden ser M partes cualesquiera. Si tienen la gráfica de una función desconocida en los dedos, los participantes intercambian puntos en la gráfica y, después de recibir M puntos, se puede restaurar toda la función.
Una buena explicación se da en wiki pero jugar con él de manera práctica para reproducir el protocolo en tu cabeza es útil para manifestación página.

Si el esquema FSSS (Fiat-Shamir Secret Sharing) fuera aplicable en su forma pura, sería un PVRB indestructible. En su forma más simple, el protocolo podría verse así:

• Cada participante genera su propio azar y lo distribuye a otros participantes.
• Cada participante revela su parte de los secretos de los demás participantes.
• Si un participante tiene más de M acciones, entonces se puede calcular el número de este participante y será único, independientemente del conjunto de participantes revelados.
• La combinación de randoms revelados es el PVRB deseado.

En este caso, un participante individual ya no influye en los resultados del protocolo, excepto en los casos en que el logro del umbral de revelación de aleatoriedad depende únicamente de él. Por lo tanto, este protocolo, si existe una proporción requerida de RP que trabajan en el protocolo y están disponibles, funciona, implementa los requisitos de solidez criptográfica y es resistente al problema del "último actor".

Esta podría ser una opción ideal, este esquema PVRB basado en el intercambio de secretos entre Fiat y Shamir se describe, por ejemplo, en este artículo. Pero, como se mencionó anteriormente, si intentas aplicarlo de frente en la cadena de bloques, aparecen limitaciones técnicas. A continuación se muestra un ejemplo de una implementación de prueba del protocolo en el contrato inteligente de EOS y su parte más importante: verificar el participante compartido publicado: código. Puede ver en el código que la validación de prueba requiere varias multiplicaciones escalares y los números utilizados son muy grandes. Debe entenderse que en blockchain la verificación ocurre en el momento en que el productor del bloque procesa la transacción y, en general, cualquier participante debe verificar fácilmente la exactitud del protocolo, por lo que los requisitos para la velocidad de la función de verificación son muy serios. . En esta opción, la opción resultó ineficaz, ya que la verificación no se ajustaba al límite de la transacción (0.5 segundos).

La eficiencia de la verificación es uno de los requisitos más importantes para el uso de, en general, cualquier esquema criptográfico avanzado en la cadena de bloques. Crear pruebas, preparar mensajes: estos procedimientos se pueden sacar de la cadena y realizar en computadoras de alto rendimiento, pero la verificación no se puede eludir; este es otro requisito importante para PVRB.

PVRB y firmas de umbral

Al familiarizarnos con el esquema de intercambio de secretos, descubrimos toda una clase de protocolos unidos por la palabra clave "umbral". Cuando la divulgación de cierta información requiere la participación de M participantes honestos de N, y el conjunto de participantes honestos puede ser un subconjunto arbitrario de N, hablamos de esquemas de “umbral”. Son ellos quienes nos permiten afrontar el problema del “último actor”, ahora si el atacante no revela su parte del secreto, otro participante honesto lo hará por él. Estos esquemas permiten llegar a un acuerdo sobre un solo significado, incluso si el protocolo es saboteado por algunos de los participantes.

La combinación de firmas deterministas y esquemas de umbral hizo posible desarrollar un esquema muy conveniente y prometedor para implementar PVRB: estas son firmas de umbral deterministas. Aquí artículo sobre los diversos usos de las firmas de umbral, y aquí hay otro bueno longread de Dash.

El último artículo describe las firmas BLS (BLS significa Boneh-Lynn-Shacham, aquí artículo), que tienen una cualidad muy importante y extremadamente conveniente para los programadores: las claves públicas, secretas, públicas y las firmas BLS se pueden combinar entre sí mediante operaciones matemáticas simples, mientras que sus combinaciones siguen siendo claves y firmas válidas, lo que le permite agregar fácilmente muchas firmas en una y muchas claves públicas en una. También son deterministas y producen el mismo resultado para los mismos datos de entrada. Debido a esta cualidad, las combinaciones de firmas BLS son en sí mismas claves válidas, lo que permite la implementación de una opción en la que M de N participantes producen una y sólo una firma que es determinista, públicamente verificable e impredecible hasta que sea abierta por el Mth. participante.

En un esquema con firmas BLS de umbral, cada participante firma algo usando BLS (por ejemplo, la firma aleatoria anterior), y la firma de umbral común es la aleatoria deseada. Las propiedades criptográficas de las firmas BLS satisfacen los requisitos de calidad aleatoria, la parte de umbral protege contra el "último actor" y la combinabilidad única de claves permite implementar muchos más algoritmos interesantes que permiten, por ejemplo, la agregación eficiente de mensajes de protocolo. .

Por lo tanto, si está creando PVRB en su cadena de bloques, lo más probable es que termine con el esquema de firmas de umbral BLS; varios proyectos ya lo están utilizando. Por ejemplo, DFinity (aquí punto de referencia que implementa el circuito, y aquí ejemplo de implementación de intercambio de secretos verificable), o Keep.network (aquí está su baliza aleatoria papel amarillo, Sin embargo, el ejemplo contrato inteligente que sirve al protocolo).

Implementación de PVRB

Desafortunadamente, todavía no vemos un protocolo listo implementado en las cadenas de bloques PVRB que haya demostrado su seguridad y estabilidad. Aunque los protocolos en sí están listos, técnicamente no es fácil aplicarlos a las soluciones existentes. Para los sistemas centralizados, PVRB no tiene sentido, y los descentralizados están estrictamente limitados en todos los recursos informáticos: CPU, memoria, almacenamiento, E/S. Diseñar un PVRB es una combinación de diferentes protocolos para crear algo que cumpla con todos los requisitos para al menos una cadena de bloques viable. Un protocolo calcula de manera más eficiente, pero requiere más mensajes entre RP, mientras que el otro requiere muy pocos mensajes, pero crear una prueba puede ser una tarea que lleva decenas de minutos o incluso horas.

Enumeraré los factores que tendrás que considerar al elegir un PVRB de calidad:

• Fuerza criptográfica. Su PVRB debe ser estrictamente imparcial, sin capacidad para controlar un solo bit. En algunos esquemas este no es el caso, así que llame a un criptógrafo.
• El problema del “último actor”. Su PVRB debe ser resistente a ataques en los que un atacante que controle uno o más RP pueda elegir uno de dos resultados.
• Problema de sabotaje de protocolo. Su PVRB debe ser resistente a ataques en los que un atacante que controla uno o más RP decide si será aleatorio o no y puede estar garantizado o con una probabilidad determinada de influir en esto.
• Problema de número de mensajes. Sus RP deben enviar un mínimo de mensajes a la cadena de bloques y evitar acciones sincrónicas tanto como sea posible, como situaciones como "Envié información, estoy esperando una respuesta de un participante específico". En redes p2p, especialmente en las geográficamente dispersas, no se debe contar con una respuesta rápida
• El problema de la complejidad computacional. La verificación de cualquier etapa del PVRB en cadena debería ser extremadamente fácil, ya que la realizan todos los clientes completos de la red. Si la implementación se realiza mediante un contrato inteligente, entonces los requisitos de velocidad son muy estrictos.
• El problema de la accesibilidad y la vivacidad. Su PVRB debe esforzarse por ser resistente a situaciones en las que parte de la red deja de estar disponible durante un período de tiempo y parte del RP simplemente deja de funcionar.
• El problema de la configuración confiable y la distribución inicial de claves. Si su PVRB utiliza la configuración principal del protocolo, entonces esta es una historia grande y seria aparte. Aquí ejemplo. Si los participantes deben comunicarse entre sí sus claves antes de iniciar el protocolo, esto también es un problema si cambia la composición de los participantes.
• Problemas de desarrollo. Disponibilidad de bibliotecas en los idiomas requeridos, su seguridad y rendimiento, publicidad, pruebas complejas, etc.

Por ejemplo, las firmas de umbral BLS tienen un problema importante: antes de comenzar a trabajar, los participantes deben distribuir claves entre sí, organizando un grupo dentro del cual trabajará el umbral. Esto significa que al menos una ronda de intercambio en una red descentralizada tendrá que esperar, y dado que el rand generado, por ejemplo, es necesario en los juegos, casi en tiempo real, esto significa que el sabotaje del protocolo es posible en esta etapa. y se pierden las ventajas del sistema de umbral. Este problema ya es más sencillo que los anteriores, pero aún requiere el desarrollo de un procedimiento separado para la formación de grupos umbral, que deberán protegerse económicamente, mediante depósitos y retiros de fondos (recortes) de los participantes que no siguen el protocolo. Además, la verificación BLS con un nivel aceptable de seguridad simplemente no encaja, por ejemplo, en una transacción estándar de EOS o Ethereum; simplemente no hay tiempo suficiente para la verificación. El código del contrato es WebAssembly o EVM, ejecutado por una máquina virtual. Las funciones criptográficas no están implementadas de forma nativa (todavía) y funcionan decenas de veces más lento que las bibliotecas criptográficas convencionales. Muchos protocolos no cumplen con los requisitos basándose simplemente en el volumen de claves, por ejemplo, 1024 y 2048 bits para RSA, de 4 a 8 veces más grande que la firma de transacción estándar en Bitcoin y Ethereum.

También influye la presencia de implementaciones en diferentes lenguajes de programación, de las cuales hay pocas, especialmente para los nuevos protocolos. La opción con integración en consenso requiere escribir un protocolo en el lenguaje de la plataforma, por lo que tendrás que buscar el código en Go para geth, en Rust para Parity, en C++ para EOS. Todo el mundo tendrá que buscar código JavaScript y, dado que JavaScript y la criptografía no son amigos muy cercanos, WebAssembly, que ahora afirma definitivamente ser el próximo estándar importante de Internet, ayudará.

Conclusión

espero en el anterior статье Logré convencerte de que generar números aleatorios en blockchain es fundamental para muchos aspectos de la vida de las redes descentralizadas, y con este artículo demostré que esta tarea es extremadamente ambiciosa y difícil, pero que ya existen buenas soluciones. En general, el diseño final del protocolo solo es posible después de realizar pruebas masivas que tengan en cuenta todos los aspectos, desde la configuración hasta la emulación de fallas, por lo que es poco probable que encuentre recetas preparadas en los documentos técnicos y artículos del equipo, y ciertamente no las encontraremos. Decida en uno o dos años escribir “hazlo de esta manera, exactamente bien”.

Adiós a nuestro PVRB en la blockchain que se está desarrollando Haya, decidimos utilizar firmas BLS de umbral, planeamos implementar PVRB a nivel de consenso, ya que aún no es posible la verificación en contratos inteligentes con un nivel aceptable de seguridad. Es posible que usemos dos esquemas a la vez: primero, compartir secretos costosos para crear una semilla aleatoria a largo plazo, y luego usarla como base para la generación aleatoria de alta frecuencia usando firmas BLS de umbral determinista, tal vez nos limitemos a solo uno de los esquemas. Desafortunadamente, es imposible decir de antemano cuál será el protocolo; lo único bueno es que, como en la ciencia, en los problemas de ingeniería, un resultado negativo también es un resultado, y cada nuevo intento de resolver el problema es un paso más para la investigación de todos los involucrados en el problema. Para cumplir con los requisitos comerciales, resolvemos un problema práctico específico: proporcionar a las aplicaciones de juegos una fuente confiable de entropía, por lo que también debemos prestar atención a la cadena de bloques en sí, en particular a las cuestiones de finalidad de la cadena y gobernanza de la red.

Y aunque todavía no vemos un PVRB resistente y probado en blockchains, que se habría utilizado durante suficiente tiempo para ser probado por aplicaciones reales, múltiples auditorías, cargas y, por supuesto, ataques reales, la cantidad de caminos posibles lo confirma. Existe una solución y cuál de estos algoritmos eventualmente resolverá el problema. Estaremos encantados de compartir los resultados y agradecer a otros equipos que también están trabajando en este tema por los artículos y códigos que permiten a los ingenieros no pisar el mismo rastrillo dos veces.

Entonces, cuando conozcas a un programador que diseña juegos aleatorios descentralizados, sé atento y afectuoso, y brinda ayuda psicológica si es necesario :)

Fuente: habr.com