Introducción

function getAbsolutelyRandomNumer() {
        return 4; // devuelve un número absolutamente aleatorio!
}

Al igual que en el caso del concepto de cifrado absolutamente resistente de la criptografía, los protocolos reales de "Publicly Verifiable Random Beacon" (en adelante PVRB) solo intentan acercarse lo más posible a un esquema ideal, ya que en redes reales no es aplicable en su forma pura: se debe negociar estrictamente un solo bit, debe haber muchas rondas y todos los mensajes deben ser perfectamente rápidos y siempre entregarse. Por supuesto, esto no es así en redes reales. Por lo tanto, al diseñar PVRB para tareas específicas en cadenas de bloques modernas, además de la imposibilidad de controlar el aleatorio obtenido y de la resistencia criptográfica, surgen muchos problemas puramente arquitectónicos y técnicos.

La propia cadena de bloques es, para el PVRB, en esencia un medio de comunicación, en el que los mensajes=transacciones. Esto permite abstraerse parcialmente de los problemas de red, la no entrega de mensajes, los problemas de software intermedio: todos estos riesgos son asumidos por la red descentralizada, y su principal valor para el PVRB es la imposibilidad de revocar o dañar una transacción ya enviada; esto impide que los participantes se retiren del protocolo, a menos que hayan llevado a cabo un ataque exitoso al consenso. Este nivel de seguridad es aceptable, por lo que el PVRB debe ser resistente a conspiraciones por parte de los participantes en la misma medida que la cadena principal de la blockchain. Además, esto sugiere que el PVRB debe ser parte del consenso; si la red se ha puesto de acuerdo sobre la cadena principal de bloques, que también se ponga de acuerdo sobre un único aleatorio resultante honesto. O bien, el PVRB es simplemente un protocolo independiente implementado mediante un contrato inteligente, que opera de manera asincrónica con respecto a la blockchain y los bloques. Ambos métodos tienen sus propias ventajas y desventajas, y la elección entre ellos es extremadamente no trivial.

Dos métodos de implementación de PVRB

Describamos con más detalle dos variantes de implementación de PVRB: la versión independiente, que funciona utilizando un contrato inteligente independiente de la blockchain, y la versión integrada en consenso, que está incrustada en el protocolo, según el cual la red se pone de acuerdo sobre la cadena de bloques y las transacciones incluidas. En todos los casos, me referiré a motores populares de blockchain: Ethereum, EOS, y todos los similares en cuanto a su funcionamiento en términos de colocación y procesamiento de contratos inteligentes.

Contrato independiente

En esta variante, 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 cierto valor que puede ser obtenido por cualquier usuario de este contrato. Este valor puede no almacenarse directamente en el contrato, sino que se puede presentar solo con datos de los que se puede determinar de forma determinista un valor único y exclusivo del resultado aleatorio. En este esquema, RP son usuarios de la blockchain, y se puede permitir la participación en el proceso de generación a cualquier persona.

La variante del contrato independiente es buena:

portabilidad (los contratos se pueden llevar de una blockchain a otra)
facilidad de implementación y pruebas (los contratos son fáciles de escribir y probar)
conveniencia en la implementación de esquemas económicos (es fácil crear su propio token cuya lógica sirva a los objetivos de PVRB)
posibilidad de implementación en blockchains ya existentes

Sin embargo, también tiene desventajas:

fuertes limitaciones en los recursos durante los cálculos, volumen de transacciones y almacenamiento (en otras palabras, cpu/mem/io)
limitaciones en las operaciones dentro del contrato (no todas las instrucciones están disponibles, es complicado conectar bibliotecas externas)
imposibilidad de organizar la comunicación más rápida que las transacciones incluidas en la blockchain

Esta variante es adecuada para implementar PVRB que se necesita poner en marcha en una red existente, que no contenga criptografía compleja y que no requiera muchas interacciones.

Integrado en el consenso

En esta variante, PVRB se implementa en el código del nodo blockchain, integrado o funcionando en paralelo con el intercambio de mensajes entre los nodos de blockchain. Los resultados del protocolo se registran directamente en los bloques generados, y los mensajes de protocolo se envían a través de la red P2P entre los nodos. Dado que el protocolo produce números que deben ser registrados en los bloques, la red debe llegar a un consenso sobre ellos. Esto significa que los mensajes de PVRB, al igual que las transacciones, deben ser validados por los nodos y ser incluidos en los bloques, de modo que cualquier participante de la red pueda validar el cumplimiento del protocolo PVRB. Esto nos lleva automáticamente a una solución obvia: si la red acuerda un consenso sobre un bloque y las transacciones en él, entonces PVRB debe ser parte del consenso, y no un protocolo separado. De lo contrario, podría darse la situación en la que un bloque sea válido desde el punto de vista del consenso, pero el protocolo PVRB no se cumpla, y desde la perspectiva de PVRB, el bloque no puede ser aceptado. Así que si se elige la variante “consensus-integrated”, PVRB se convierte en una parte importante del consenso.

Al describir las implementaciones de PVRB a nivel de consenso en la red, no se pueden omitir en absoluto las cuestiones de finalización. La finalización es un mecanismo utilizado en consensos determinísticos que fija un bloque (y la cadena que lo lleva) como final, el cual nunca será descartado, incluso si aparece un fork paralelo. Por ejemplo, en Bitcoin no existe tal mecanismo: si se publica una cadena de mayor complejidad, reemplazará cualquier cadena menos compleja, sin importar la longitud de las cadenas. En EOS, por otro lado, los últimos bloques irrefutables, conocidos como Last Irreversible Blocks, aparecen en promedio cada 432 bloques (12*21 + 12*15, pre-vote + pre-commit). Este proceso consiste esencialmente en esperar la firma de 2/3 de los block-producers (en adelante BP). Cuando aparecen forks que son más antiguos que el último LIB, simplemente se descartan. Este mecanismo garantiza que una transacción esté incluida en la blockchain y nunca será revertida, sin importar los recursos del atacante. Además, los bloques finales son aquellos firmados por 2/3 de BP en Hyperledger, Tendermint y otros consensos basados en pBFT. Asimismo, tiene sentido construir un protocolo para garantizar la finalización como una extensión del consenso, ya que puede funcionar de forma asíncrona con la producción y publicación de bloques. Windows sobre la finalización en Ethereum.

La finalización es extremadamente importante para los usuarios, quienes sin ella pueden ser víctimas de un ataque de “doble gasto”, cuando el BP “retiene” bloques y los publica después de que la red haya “visto” una buena transacción. Si no hay finalización, el fork publicado reemplaza el bloque con la transacción “buena” por otro del fork “malo”, donde esos mismos fondos se transfieren a la dirección del atacante. En el caso de PVRB, los requisitos para la finalización son aún más estrictos, ya que la creación de forks para PVRB significa que el atacante puede preparar varias versiones del aleatorio con el objetivo de publicar la más ventajosa para él, y limitar el tiempo de un posible ataque — es una buena solución.

Por lo tanto, la mejor opción es combinar PVRB y finalización en un solo protocolo — así, un bloque finalizado = un aleatorio finalizado, y eso es exactamente lo que se necesitaba. Ahora los jugadores recibirán un aleatorio garantizado en N segundos, y pueden estar seguros de que no se puede revertir o rehacer.

La opción con consenso integrado es buena:

con la posibilidad de implementación asíncrona en relación con la producción de bloques — los bloques se producen como de costumbre, pero paralelamente puede funcionar el protocolo PVRB, que genera aleatorios no cada bloque
con la posibilidad de implementar incluso criptografía pesada, sin las limitaciones impuestas a los contratos inteligentes
con la posibilidad 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 la difusión de mensajes a través de la red

Sin embargo, también tiene desventajas:

dificultades en las pruebas y desarrollo — será necesario emular errores de red, nodos perdidos, hard forks de la red
los errores en la implementación requieren un hard fork de la red

Ambos métodos de implementación de PVRB tienen derecho a existir, pero la implementación en contratos inteligentes en las cadenas de bloques modernas está bastante limitada en recursos computacionales, y cualquier transición a una criptografía seria a menudo es simplemente imposible. Y necesitaremos criptografía seria, como se demostrará más adelante. Sin embargo, este problema es claramente temporal, la criptografía seria en los contratos es necesaria para resolver muchas tareas, y poco a poco está apareciendo (por ejemplo, contratos sistémicos para zkSNARKs en Ethereum).

La blockchain que proporciona un canal de mensajería del 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 llevada a cabo por fuerzas acordadas de múltiples cuentas, por lo que al diseñar es necesario considerar las posibilidades de los atacantes para crear un número arbitrario de participantes en el protocolo que actúan en conjunto.

PVRB y variables de bloque.

No mentía cuando decía que un buen PVRB, verificado por muchas aplicaciones de gambling, aún no se ha implementado en blockchains. Entonces, ¿de dónde proviene esa cantidad de aplicaciones de gambling en Ethereum y EOS? Me sorprende tanto como a ustedes; ¿de dónde han sacado tantos “aleatorios” “resistentes” en un entorno completamente determinista?

La forma favorita de obtener aleatoriedad en la blockchain es tomar alguna información “impredecible” del bloque y, sobre la base de esta, generar aleatoriedad simplemente aplicando hashes a uno o varios valores. Un buen artículo sobre los problemas de estos esquemas. aquíSe puede tomar alguno de los valores “impredecibles” en el bloque, como el hash del bloque, el número de transacciones, la dificultad de la red y otros valores desconocidos de antemano. Luego, se hashéa uno o varios y, en teoría, debería resultar una verdadera aleatoriedad. Incluso se podría añadir en el whitepaper que su esquema es “post-cuántico seguro” (ya que existen funciones hash a prueba de cuántica :).

Pero, lamentablemente, incluso los hashes post-cuánticos no son suficientes. El secreto está en los requisitos del PVRB, los recordaré de un artículo anterior:

El resultado debe tener una distribución demostrablemente uniforme, es decir, estar basado en criptografía demostrablemente resistente.
No se puede controlar ninguno de los bits del resultado. Como consecuencia, el resultado no puede ser predicho de antemano.
No se puede sabotear el protocolo de generación por no participar en el protocolo o mediante la sobrecarga de la red con mensajes agresivos.
Todo lo anterior debe ser resistente a conspiraciones de un número aceptable de participantes deshonestos en el protocolo (por ejemplo, 1/3 de los participantes).

En este caso, se cumple solo el requisito 1, y no se cumple el 2. Al hash de valores impredecibles del bloque, obtendremos una distribución uniforme y buenos números aleatorios. Pero el BP tiene al menos la opción de “publicar el bloque o no”. Así, el BP puede elegir al menos entre DOS opciones de aleatorización: la “suyo” y aquella que podría resultar si el bloque lo crea otra persona. El BP puede “espiar” de antemano qué sucederá si publica el bloque y simplemente decide hacerlo o no. De esta manera, jugando, por ejemplo, a “par-impar” o “rojo/negro” en la ruleta, solo puede publicar el bloque si ve una ganancia. Esto también hace que sea inviable la estrategia de usar, por ejemplo, el hash del bloque “del futuro”. En este caso, se dice que “se utilizará un número aleatorio que resulta del hashing de los datos actuales y el hash del bloque futuro a una altura de, por ejemplo, N + 42, donde N es la altura actual del bloque. Esto refuerza un poco el esquema, pero aún permite al BP, aunque sea en el futuro, decidir retener el bloque o publicarlo.

El software del BP en este caso se complica, pero no mucho. Simplemente, al validar e incluir una transacción en el bloque, se hace una rápida verificación de si habrá una ganancia, y, posiblemente, se ajusta uno de los parámetros de la transacción para obtener una alta probabilidad de ganar. Además, atrapar a un BP astuto con tales manipulaciones es prácticamente imposible; se pueden usar nuevas direcciones cada vez y ganar poco a poco, sin levantar sospechas.

Por lo tanto, los métodos que utilizan información del bloque no son adecuados como implementación universal de PVRB. En una variante limitada, con restricciones en los tamaños de las apuestas, limitaciones en la cantidad de jugadores y/o con registro KYC (para evitar que un solo jugador utilice múltiples direcciones), estos esquemas pueden funcionar para juegos pequeños, pero no más que eso.

PVRB y commit-reveal.

Bueno, gracias al hashing y al menos a la relativa imprevisibilidad del hash del bloque y de otras variables. Si se resuelve el problema del front-running de los mineros, debería resultar algo más sólido. Vamos a añadir a los usuarios en este esquema — que también influyan en el azar: cualquier empleado de soporte técnico le dirá que lo más aleatorio en los sistemas IT 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, el hash de su suma, no es adecuado. En este caso, el último jugador que juega puede controlar el resultado eligiendo su propio número aleatorio. Por lo tanto, se utiliza un patrón muy común llamado commit-reveal. Los participantes primero envían hashes de sus números aleatorios (commits) y luego revelan los números aleatorios (reveals). La fase de 'reveal' comienza solo después de que se hayan recopilado los commits necesarios, por lo que los participantes pueden enviar exactamente el número aleatorio del que enviaron anteriormente el hash. Ahora combinamos todo esto con los parámetros del bloque, preferiblemente tomados del futuro (el número aleatorio solo se podrá conocer en uno de los bloques futuros), ¡y voilà, el número aleatorio está listo! Ahora cualquier jugador influye en el número aleatorio resultante y puede 'vencer' a un BP malicioso, superponiendo su número aleatorio con un número desconocido de antemano... También se puede agregar protección contra el sabotaje del protocolo al no revelar en la etapa de reveal, simplemente exigiendo que al hacer un commit se adjunte una cierta cantidad a la transacción: un depósito de seguridad que solo se devolverá durante el procedimiento de reveal. En este caso, hacer un commit y no hacer un reveal no será rentable.

Fue un buen intento, y existen tales esquemas en las DApp de juegos, pero desafortunadamente, esto nuevamente no es suficiente. Ahora el resultado puede ser influenciado no solo por el minero, sino también por cualquier participante del protocolo. Controlar el valor en sí todavía es posible, con menor variabilidad y a cambio de dinero, pero, como en el caso del minero, si los resultados del concurso son más valiosos que la tarifa de participación en el protocolo PVRB, entonces el random-producer (RP) puede decidir si hace el reveal y todavía puede elegir entre al menos dos opciones de números aleatorios.
Sin embargo, ahora hay la posibilidad de castigar a quienes hacen un commit y no hacen un reveal, y este esquema aún será útil. Su simplicidad es una ventaja significativa: protocolos más complejos requieren cálculos mucho más potentes.

PVRB y firmas deterministas.

Hay otra forma de hacer que el RP proporcione un número aleatorio pseudoaleatorio sobre el cual no podrá influir si se le proporciona un 'modelo': se trata de una firma determinista. Una de estas firmas es, por ejemplo, RSA, y no lo es ECS. Si el RP tiene un par de claves: RSA y EСC, y firma un valor con su clave privada, en el caso de RSA solo obtendrá UNA Y SOLA FIRMA, mientras que en el caso de ECS puede generar un número arbitrario de firmas válidas diferentes. Esto se debe a que al crear una firma ECS se utiliza un número aleatorio elegido por el firmante, el cual puede ser seleccionado libremente, lo que le da al firmante la opción de elegir entre varias firmas. En el caso de RSA: 'un valor de entrada' + 'un par de claves' = 'una firma'. No se puede predecir qué firma tendrá otro RP, por lo que el PVRB con firmas deterministas puede organizarse combinando las firmas RSA de varios participantes que hayan firmado el mismo valor. Por ejemplo: el número aleatorio anterior. En este esquema se ahorra bastante recurso, ya que las firmas son al mismo tiempo 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 publica su firma o no, controlando así el resultado. Se pueden mejorar los esquemas, añadiendo hashes de bloques, realizando rondas para que el resultado no se pueda predecir por adelantado, pero todas estas técnicas, incluso considerando múltiples mejoras, aún dejan sin resolver el problema de la influencia de un participante en el resultado colectivo en un entorno no confiable y solo pueden funcionar bajo condiciones de limitaciones económicas y temporales. Además, el tamaño de las claves RSA (1024 y 2048 bits) es bastante grande, y el tamaño para transacciones en blockchain es un parámetro extremadamente importante. Aparentemente, no se podrá resolver el problema de manera simple, sigamos adelante.

En criptografía existen esquemas que permiten a la red acordar un solo valor de PVRB, siendo estos esquemas resistentes a cualquier acción maliciosa de parte de los participantes. Uno de los protocolos útiles que vale la pena conocer es el esquema de secreto compartido de Shamir. Este sirve para dividir un secreto (por ejemplo, una clave secreta) en varias partes y distribuir esas partes a N participantes. El secreto se distribuye de tal manera que para su recuperación son suficientes M partes de N, pudiendo ser cualquiera de esas M partes. Si lo explicamos de manera sencilla, al tener un gráfico de una función desconocida, los participantes intercambian puntos en el gráfico, y después de obtener M puntos, se puede recuperar toda la función.
Una buena explicación se encuentra en wiki y para jugar con ello de manera práctica, es útil usarlo en demo página.

Si el esquema FSSS (Fiat-Shamir Secret Sharing) se aplicara de manera pura, sería un PVRB invulnerable. En su forma más simple, el protocolo puede verse así:

Cada participante genera su propio aleatorio y reparte participaciones de él a los demás participantes.
Cada participante revela su parte de los secretos de los demás participantes.
Si un participante acumula más de M participaciones, se puede calcular el número de ese participante, y será único, independientemente del conjunto de participantes que revelaron sus secretos.
La combinación de los aleatorios revelados es el PVRB buscado.

Aquí, un participante individual ya no influye en los resultados del protocolo, excepto en los casos en que su participación sea la única que determine el umbral para revelar el aleatorio. Por lo tanto, este protocolo, dado que tiene la proporción necesaria de participantes siguiendo el protocolo y RP disponibles, cumple con los requisitos de resistencia criptográfica y es resistente al problema del “último actor”.

Este podría ser el escenario ideal, el esquema de PVRB basado en el secreto compartido de Fiat-Shamir está descrito, por ejemplo, en esta el artículo. Pero, como se mencionó anteriormente, si se intenta aplicarlo directamente en blockchain, surgen limitaciones técnicas. Aquí tienes un ejemplo de la implementación de un protocolo en un contrato inteligente de EOS y su parte más importante: la verificación de la participación publicada por el participante: código. Por el código, se puede ver que la validación del proof requiere varias multiplicaciones escalares, y se utilizan números muy grandes. Es importante entender que en las blockchains la verificación ocurre en el momento en que el bloque productor procesa la transacción, y cualquier participante debe poder verificar fácilmente la correcta implementación del protocolo, por lo que los requisitos de velocidad para la función de verificación son muy estrictos. En este caso, la alternativa resultó ser inviable, ya que la verificación no cumplió con el límite de tiempo de la transacción (0.5 seg).

La eficacia de la verificación es uno de los requisitos más importantes para el uso de cualquier esquema criptográfico avanzado en blockchain. La creación de proofs y la preparación de mensajes son procedimientos que se pueden realizar off-chain en computadoras de alto rendimiento, pero la verificación no se puede eludir, este es otro requisito importante para PVRB.

PVRB y firmas umbral

Al familiarizarnos con el esquema de secret sharing, hemos abierto toda una clase de protocolos reunidos bajo la palabra clave “threshold”. Cuando para revelar cierta información se requiere la participación de M participantes honestos de un conjunto N, y el grupo de participantes honestos puede ser un subconjunto arbitrario de N, se habla de esquemas “threshold”. Estos permiten abordar el problema del “último actor”, ya que si un atacante no revela su parte del secreto, otro participante honesto lo hará. Estos esquemas permiten acordar un único valor, incluso ante el sabotaje del protocolo por parte de algunos participantes.

La combinación de firmas deterministas y esquemas de threshold ha permitido desarrollar un esquema muy conveniente y prometedor para la implementación de PVRB: se trata de firmas umbral deterministas. Aquí Windows sobre diversas aplicaciones de las firmas umbral, y aquí hay otro buen ejemplo longread de Dash.

El último artículo describe las firmas BLS (BLS se descompone como Boneh-Lynn-Shacham, aquí artículo ), que tienen una cualidad muy importante y extremadamente conveniente para los programadores: las claves públicas, secretas y las firmas BLS pueden combinarse entre sí a través de operaciones matemáticas simples, manteniendo al mismo tiempo que sus combinaciones siguen siendo claves y firmas válidas, lo que permite agregar fácilmente muchas firmas en una sola y muchas claves públicas en una. También poseen determinismo y, con los mismos datos de entrada, producen el mismo resultado. Gracias a esta cualidad, las combinaciones de firmas BLS en sí mismas son claves válidas, lo que permite implementar una variante donde M de N participantes producen una única firma, que es determinada, públicamente verificable e impredecible hasta que sea revelada por el M-ésimo participante.

En el esquema de firmas BLS de umbral, cada participante firma algo (por ejemplo, el aleatorio anterior) utilizando BLS, y la firma total de umbral es el aleatorio deseado. Las propiedades criptográficas de las firmas BLS cumplen con los requisitos de calidad del aleatorio, la parte de umbral protege contra el “último actor”, y la única combinabilidad de las claves permite implementar muchos algoritmos interesantes que, por ejemplo, permiten agregar de manera eficiente los mensajes del protocolo.

Así que, si estás construyendo PVRB en tu blockchain, es muy probable que llegues al esquema de firmas BLS de umbral, que ya utilizan varios proyectos. Por ejemplo, DFinity (aquí benchmark, implementando el esquema, y aquí un ejemplo de implementación de compartición secreta verificable), o Keep.network (aquí su random beacon yellowpaper, pero ejemplo smart contract que soporta el protocolo).

Implementación de PVRB

Lamentablemente, aún no vemos un protocolo para PVRB que haya sido implementado en blockchains y que haya demostrado su seguridad y resiliencia. Aunque los propios protocolos están listos, aplicarlos técnicamente a soluciones existentes no es fácil. Para sistemas centralizados, PVRB no tiene sentido, y los descentralizados están estrictamente limitados en todos los recursos computacionales: CPU, memoria, almacenamiento, I/O. El diseño de PVRB consiste en combinar diferentes protocolos para crear algo que cumpla con todos los requisitos, al menos para algún blockchain viable. Un protocolo calcula de manera más eficiente, pero requiere más mensajes entre los RP, mientras que otro requiere muy pocos mensajes, pero la generación de una prueba puede tomar decenas de minutos o incluso horas.

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

Resistencia criptográfica. Su PVRB debe ser estrictamente inalterable, sin la posibilidad de controlar un solo bit. En algunos esquemas, esto no es así, por lo que debe consultar a un criptógrafo.
Problema del “último actor”. Su PVRB debe ser resistente a ataques en los que un atacante que controla uno o varios RP puede elegir entre dos resultados.
Problema del sabotaje del protocolo. Su PVRB debe ser resistente a ataques en los que un atacante que controla uno o varios RP decide si hay o no aleatoriedad y puede influir garantizando o con una probabilidad determinada.
Problema de la cantidad de mensajes. Sus RP deben enviar al blockchain el mínimo de mensajes y evitar al máximo acciones síncronas, como situaciones de “he enviado cierta información, estoy esperando una respuesta de un participante específico”. En redes p2p, especialmente geográficamente dispersas, no se debe contar con una respuesta rápida.
Problema de la complejidad computacional. La verificación de cualquier etapa del PVRB en la cadena debe ser extremadamente sencilla, ya que la realizan todos los nodos completos de la red. Si la implementación se hace mediante un contrato inteligente, entonces los requisitos de velocidad son muy estrictos.
Problema de disponibilidad y liveness. Su PVRB debe esforzarse por ser resistente a situaciones en las que parte de la red se vuelve inaccesible durante un tiempo y algunos RP dejan de funcionar.
Problema de la configuración confiable y la distribución inicial de claves.. Si su PVRB utiliza una configuración primaria del protocolo, esa es una historia separada y seria. Aquí está ejemplo. Si los participantes deben intercambiar sus claves antes de que inicie el protocolo, también es un problema si la composición de los participantes cambia
Problemas de desarrollo. La disponibilidad de bibliotecas en los lenguajes necesarios, su seguridad y rendimiento, la publicidad, pruebas complejas, etc.

Por ejemplo, el esquema de firmas BLS umbral tiene un problema significativo: antes de empezar a trabajar, los participantes deben repartirse sus claves, organizando un grupo dentro del cual funcionará el umbral. Esto significa que al menos una ronda de intercambio en una red descentralizada tendrá que esperarse y, considerando que el random generado, por ejemplo, es necesario en juegos, prácticamente en tiempo real, esto significa que el sabotaje del protocolo es posible en esta etapa, y las ventajas del esquema umbral se pierden. Este problema es ya más manejable que los anteriores, pero aún así requiere el desarrollo de un procedimiento separado para la formación de grupos umbral, que deberá ser protegido económicamente, mediante depósitos y la reducción de fondos (slashing) de los participantes que no sigan el protocolo. Además, la verificación BLS con un nivel de seguridad aceptable 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 de los contratos es WebAssembly o EVM, ejecutado por una máquina virtual. Las funciones criptográficas no se implementan de forma nativa (por ahora), y funcionan varias veces más lentas que las bibliotecas criptográficas estándar. Muchos protocolos no cumplen con los requisitos simplemente por el volumen de las claves, por ejemplo, son 1024 y 2048 bits para RSA, de 4 a 8 veces más que la firma estándar de una transacción en Bitcoin y Ethereum.

También juega un papel la disponibilidad de implementaciones en diferentes lenguajes de programación, que son escasas, especialmente para nuevos protocolos. La opción de integración en el consenso requiere escribir el protocolo en el lenguaje de la plataforma, así que se tendrá que buscar código en Go para geth, en Rust para Parity, en C++ para EOS. El código en JavaScript habrá que buscarlo por todos, y dado que JavaScript y la criptografía no son amigos cercanos, será útil WebAssembly, que ahora definitivamente aspira a ser el próximo estándar importante de Internet.

Conclusión

Espero que en el anterior el artículo He logrado convencerte de que la generación de números aleatorios en la cadena de bloques es críticamente importante para muchos aspectos de la vida de las redes descentralizadas, y en este artículo he demostrado que esta tarea es extremadamente ambiciosa y difícil, pero ya existen buenas soluciones. En general, el diseño final del protocolo solo es posible después de llevar a cabo pruebas masivas que tengan en cuenta todos los aspectos, desde la configuración hasta la simulación de fallos, por lo que es poco probable que encuentres recetas listas en los whitepapers de los equipos o en los artículos, y tampoco nos atreveremos a escribir en el próximo año o dos 'hace esto, así es definitivamente correcto'.

Por ahora, para nuestro PVRB en la cadena de bloques en desarrollo Haya, hemos decidido aplicar firmas BLS de umbral, planeamos implementar PVRB a nivel de consenso, ya que la verificación en contratos inteligentes con un nivel aceptable de seguridad aún es imposible. Es posible que utilicemos dos esquemas: primero, el costoso secret sharing para crear una semilla aleatoria a largo plazo, que luego utilizaremos como base para la generación de aleatoriedad de alta frecuencia mediante firmas BLS de umbral determinísticas, y quizás nos limitemos a uno solo de los esquemas. Decir de antemano cuál será el protocolo, lamentablemente, es imposible, lo que alegra es que, al igual que 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 nuevo escalón para la investigación de todos los que están involucrados en el tema. Para satisfacer las demandas del negocio, estamos resolviendo una tarea práctica específica: proporcionar a las aplicaciones de juego una fuente confiable de entropía, por lo que también tenemos que prestar atención a la propia cadena de bloques, en particular a cuestiones de finalización de la cadena y gobernanza de la red.

Y aunque por ahora no vemos en las cadenas de bloques un PVRB comprobablemente resistente que haya sido utilizado el tiempo suficiente como para superar las pruebas de aplicaciones reales, múltiples auditorías, cargas y, por supuesto, ataques reales, el número de posibles caminos confirma que la solución existe y que alguno de estos algoritmos, al final, resolverá el problema. Estaremos encantados de compartir los resultados y agradecemos a otros equipos que también están trabajando en este tema por los artículos y el código que permiten a los ingenieros no caer dos veces en las mismas trampas.

Así que, al encontrarte con un programador que diseña un random descentralizado, sé cauteloso y considerado, y ofrece apoyo psicológico si es necesario 🙂

Fuente: habr.com