{"id":33888,"date":"2019-10-31T21:55:15","date_gmt":"2019-10-31T18:55:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\/"},"modified":"2019-10-31T21:55:15","modified_gmt":"2019-10-31T18:55:15","slug":"sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","title":{"rendered":"N\u00fameros aleatorios y redes descentralizadas: implementaciones","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1 id=\"vvedenie\">Introducci\u00f3n<\/h1>\n<p><\/p>\n<pre><code class=\"plaintext\">function getAbsolutelyRandomNumer() {\n        return 4; \/\/ devuelve un n\u00famero absolutamente aleatorio!\n}<\/code><\/pre>\n<p><\/p>\n<p>Al igual que en el caso del concepto de cifrado absolutamente resistente de la criptograf\u00eda, los protocolos reales de \"Publicly Verifiable Random Beacon\" (en adelante PVRB) solo intentan acercarse lo m\u00e1s 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\u00e1pidos y siempre entregarse. Por supuesto, esto no es as\u00ed en redes reales. Por lo tanto, al dise\u00f1ar PVRB para tareas espec\u00edficas en cadenas de bloques modernas, adem\u00e1s de la imposibilidad de controlar el aleatorio obtenido y de la resistencia criptogr\u00e1fica, surgen muchos problemas puramente arquitect\u00f3nicos y t\u00e9cnicos.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>La propia cadena de bloques es, para el PVRB, en esencia un medio de comunicaci\u00f3n, 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\u00f1ar una transacci\u00f3n 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\u00e1s, 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\u00e9n se ponga de acuerdo sobre un \u00fanico aleatorio resultante honesto. O bien, el PVRB es simplemente un protocolo independiente implementado mediante un contrato inteligente, que opera de manera asincr\u00f3nica con respecto a la blockchain y los bloques. Ambos m\u00e9todos tienen sus propias ventajas y desventajas, y la elecci\u00f3n entre ellos es extremadamente no trivial. <\/p>\n<p><\/p>\n<h2 id=\"dva-sposoba-implementacii-pvrb\">Dos m\u00e9todos de implementaci\u00f3n de PVRB<\/h2>\n<p><\/p>\n<p>Describamos con m\u00e1s detalle dos variantes de implementaci\u00f3n de PVRB: la versi\u00f3n independiente, que funciona utilizando un contrato inteligente independiente de la blockchain, y la versi\u00f3n integrada en consenso, que est\u00e1 incrustada en el protocolo, seg\u00fan el cual la red se pone de acuerdo sobre la cadena de bloques y las transacciones incluidas. En todos los casos, me referir\u00e9 a motores populares de blockchain: Ethereum, EOS, y todos los similares en cuanto a su funcionamiento en t\u00e9rminos de colocaci\u00f3n y procesamiento de contratos inteligentes. <\/p>\n<p><\/p>\n<h3 id=\"standalone-contract\">Contrato independiente<\/h3>\n<p><\/p>\n<p>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 \u00fanico y exclusivo del resultado aleatorio. En este esquema, RP son usuarios de la blockchain, y se puede permitir la participaci\u00f3n en el proceso de generaci\u00f3n a cualquier persona.<\/p>\n<p><\/p>\n<p>La variante del contrato independiente es buena:<\/p>\n<p><\/p>\n<ul>\n<li>portabilidad (los contratos se pueden llevar de una blockchain a otra)<\/li>\n<li>facilidad de implementaci\u00f3n y pruebas (los contratos son f\u00e1ciles de escribir y probar)<\/li>\n<li>conveniencia en la implementaci\u00f3n de esquemas econ\u00f3micos (es f\u00e1cil crear su propio token cuya l\u00f3gica sirva a los objetivos de PVRB)<\/li>\n<li>posibilidad de implementaci\u00f3n en blockchains ya existentes<\/li>\n<\/ul>\n<p><\/p>\n<p>Sin embargo, tambi\u00e9n tiene desventajas:<\/p>\n<p><\/p>\n<ul>\n<li>fuertes limitaciones en los recursos durante los c\u00e1lculos, volumen de transacciones y almacenamiento (en otras palabras, cpu\/mem\/io)<\/li>\n<li>limitaciones en las operaciones dentro del contrato (no todas las instrucciones est\u00e1n disponibles, es complicado conectar bibliotecas externas)<\/li>\n<li>imposibilidad de organizar la comunicaci\u00f3n m\u00e1s r\u00e1pida que las transacciones incluidas en la blockchain<\/li>\n<\/ul>\n<p><\/p>\n<p>Esta variante es adecuada para implementar PVRB que se necesita poner en marcha en una red existente, que no contenga criptograf\u00eda compleja y que no requiera muchas interacciones.<\/p>\n<p><\/p>\n<h3 id=\"consensus-integrated\">Integrado en el consenso<\/h3>\n<p><\/p>\n<p>En esta variante, PVRB se implementa en el c\u00f3digo 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\u00edan a trav\u00e9s de la red P2P entre los nodos. Dado que el protocolo produce n\u00fameros 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\u00e1ticamente a una soluci\u00f3n obvia: si la red acuerda un consenso sobre un bloque y las transacciones en \u00e9l, entonces PVRB debe ser parte del consenso, y no un protocolo separado. De lo contrario, podr\u00eda darse la situaci\u00f3n en la que un bloque sea v\u00e1lido 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\u00ed que si se elige la variante \u201cconsensus-integrated\u201d, PVRB se convierte en una parte importante del consenso.<\/p>\n<p><\/p>\n<p>Al describir las implementaciones de PVRB a nivel de consenso en la red, no se pueden omitir en absoluto las cuestiones de finalizaci\u00f3n. La finalizaci\u00f3n es un mecanismo utilizado en consensos determin\u00edsticos que fija un bloque (y la cadena que lo lleva) como final, el cual nunca ser\u00e1 descartado, incluso si aparece un fork paralelo. Por ejemplo, en Bitcoin no existe tal mecanismo: si se publica una cadena de mayor complejidad, reemplazar\u00e1 cualquier cadena menos compleja, sin importar la longitud de las cadenas. En EOS, por otro lado, los \u00faltimos 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\u00e1s antiguos que el \u00faltimo LIB, simplemente se descartan. Este mecanismo garantiza que una transacci\u00f3n est\u00e9 incluida en la blockchain y nunca ser\u00e1 revertida, sin importar los recursos del atacante. Adem\u00e1s, 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\u00f3n como una extensi\u00f3n del consenso, ya que puede funcionar de forma as\u00edncrona con la producci\u00f3n y publicaci\u00f3n de bloques. <noindex><a rel=\"nofollow\" href=\"https:\/\/arxiv.org\/pdf\/1710.09437.pdf\">Windows<\/a><\/noindex> sobre la finalizaci\u00f3n en Ethereum.<\/p>\n<p><\/p>\n<p>La finalizaci\u00f3n es extremadamente importante para los usuarios, quienes sin ella pueden ser v\u00edctimas de un ataque de \u201cdoble gasto\u201d, cuando el BP \u201cretiene\u201d bloques y los publica despu\u00e9s de que la red haya \u201cvisto\u201d una buena transacci\u00f3n. Si no hay finalizaci\u00f3n, el fork publicado reemplaza el bloque con la transacci\u00f3n \u201cbuena\u201d por otro del fork \u201cmalo\u201d, donde esos mismos fondos se transfieren a la direcci\u00f3n del atacante. En el caso de PVRB, los requisitos para la finalizaci\u00f3n son a\u00fan m\u00e1s estrictos, ya que la creaci\u00f3n de forks para PVRB significa que el atacante puede preparar varias versiones del aleatorio con el objetivo de publicar la m\u00e1s ventajosa para \u00e9l, y limitar el tiempo de un posible ataque \u2014 es una buena soluci\u00f3n.<\/p>\n<p><\/p>\n<p>Por lo tanto, la mejor opci\u00f3n es combinar PVRB y finalizaci\u00f3n en un solo protocolo \u2014 as\u00ed, un bloque finalizado = un aleatorio finalizado, y eso es exactamente lo que se necesitaba. Ahora los jugadores recibir\u00e1n un aleatorio garantizado en N segundos, y pueden estar seguros de que no se puede revertir o rehacer.<\/p>\n<p><\/p>\n<p>La opci\u00f3n con consenso integrado es buena:<\/p>\n<p><\/p>\n<ul>\n<li>con la posibilidad de implementaci\u00f3n as\u00edncrona en relaci\u00f3n con la producci\u00f3n de bloques \u2014 los bloques se producen como de costumbre, pero paralelamente puede funcionar el protocolo PVRB, que genera aleatorios no cada bloque<\/li>\n<li>con la posibilidad de implementar incluso criptograf\u00eda pesada, sin las limitaciones impuestas a los contratos inteligentes<\/li>\n<li>con la posibilidad de organizar el intercambio de mensajes m\u00e1s r\u00e1pido que las transacciones se incluyen en la cadena de bloques, por ejemplo, parte del protocolo puede funcionar entre nodos sin la difusi\u00f3n de mensajes a trav\u00e9s de la red<\/li>\n<\/ul>\n<p><\/p>\n<p>Sin embargo, tambi\u00e9n tiene desventajas:<\/p>\n<p><\/p>\n<ul>\n<li>dificultades en las pruebas y desarrollo \u2014 ser\u00e1 necesario emular errores de red, nodos perdidos, hard forks de la red<\/li>\n<li>los errores en la implementaci\u00f3n requieren un hard fork de la red<\/li>\n<\/ul>\n<p><\/p>\n<p>Ambos m\u00e9todos de implementaci\u00f3n de PVRB tienen derecho a existir, pero la implementaci\u00f3n en contratos inteligentes en las cadenas de bloques modernas est\u00e1 bastante limitada en recursos computacionales, y cualquier transici\u00f3n a una criptograf\u00eda seria a menudo es simplemente imposible. Y necesitaremos criptograf\u00eda seria, como se demostrar\u00e1 m\u00e1s adelante. Sin embargo, este problema es claramente temporal, la criptograf\u00eda seria en los contratos es necesaria para resolver muchas tareas, y poco a poco est\u00e1 apareciendo (por ejemplo, contratos sist\u00e9micos para zkSNARKs en Ethereum).<\/p>\n<p><\/p>\n<p>La blockchain que proporciona un canal de mensajer\u00eda 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\u00f3n puede ser llevada a cabo por fuerzas acordadas de m\u00faltiples cuentas, por lo que al dise\u00f1ar es necesario considerar las posibilidades de los atacantes para crear un n\u00famero arbitrario de participantes en el protocolo que act\u00faan en conjunto. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-peremennye-bloka\">PVRB y variables de bloque.<\/h2>\n<p><\/p>\n<p>No ment\u00eda cuando dec\u00eda que un buen PVRB, verificado por muchas aplicaciones de gambling, a\u00fan no se ha implementado en blockchains. Entonces, \u00bfde d\u00f3nde proviene esa cantidad de aplicaciones de gambling en Ethereum y EOS? Me sorprende tanto como a ustedes; \u00bfde d\u00f3nde han sacado tantos \u201caleatorios\u201d \u201cresistentes\u201d en un entorno completamente determinista?<\/p>\n<p><\/p>\n<p>La forma favorita de obtener aleatoriedad en la blockchain es tomar alguna informaci\u00f3n \u201cimpredecible\u201d del bloque y, sobre la base de esta, generar aleatoriedad simplemente aplicando hashes a uno o varios valores. Un buen art\u00edculo sobre los problemas de estos esquemas. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.positive.com\/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620\">aqu\u00ed<\/a><\/noindex>Se puede tomar alguno de los valores \u201cimpredecibles\u201d en el bloque, como el hash del bloque, el n\u00famero de transacciones, la dificultad de la red y otros valores desconocidos de antemano. Luego, se hash\u00e9a uno o varios y, en teor\u00eda, deber\u00eda resultar una verdadera aleatoriedad. Incluso se podr\u00eda a\u00f1adir en el whitepaper que su esquema es \u201cpost-cu\u00e1ntico seguro\u201d (ya que existen funciones hash a prueba de cu\u00e1ntica :).<\/p>\n<p><\/p>\n<p>Pero, lamentablemente, incluso los hashes post-cu\u00e1nticos no son suficientes. El secreto est\u00e1 en los requisitos del PVRB, los recordar\u00e9 de un art\u00edculo anterior:<\/p>\n<p><\/p>\n<ol>\n<li>El resultado debe tener una distribuci\u00f3n demostrablemente uniforme, es decir, estar basado en criptograf\u00eda demostrablemente resistente.<\/li>\n<li>No se puede controlar ninguno de los bits del resultado. Como consecuencia, el resultado no puede ser predicho de antemano.<\/li>\n<li>No se puede sabotear el protocolo de generaci\u00f3n por no participar en el protocolo o mediante la sobrecarga de la red con mensajes agresivos.<\/li>\n<li>Todo lo anterior debe ser resistente a conspiraciones de un n\u00famero aceptable de participantes deshonestos en el protocolo (por ejemplo, 1\/3 de los participantes).<\/li>\n<\/ol>\n<p><\/p>\n<p>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\u00f3n uniforme y buenos n\u00fameros aleatorios. Pero el BP tiene al menos la opci\u00f3n de \u201cpublicar el bloque o no\u201d. As\u00ed, el BP puede elegir al menos entre DOS opciones de aleatorizaci\u00f3n: la \u201csuyo\u201d y aquella que podr\u00eda resultar si el bloque lo crea otra persona. El BP puede \u201cespiar\u201d de antemano qu\u00e9 suceder\u00e1 si publica el bloque y simplemente decide hacerlo o no. De esta manera, jugando, por ejemplo, a \u201cpar-impar\u201d o \u201crojo\/negro\u201d en la ruleta, solo puede publicar el bloque si ve una ganancia. Esto tambi\u00e9n hace que sea inviable la estrategia de usar, por ejemplo, el hash del bloque \u201cdel futuro\u201d. En este caso, se dice que \u201cse utilizar\u00e1 un n\u00famero 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\u00fan permite al BP, aunque sea en el futuro, decidir retener el bloque o publicarlo.<\/p>\n<p><\/p>\n<p>El software del BP en este caso se complica, pero no mucho. Simplemente, al validar e incluir una transacci\u00f3n en el bloque, se hace una r\u00e1pida verificaci\u00f3n de si habr\u00e1 una ganancia, y, posiblemente, se ajusta uno de los par\u00e1metros de la transacci\u00f3n para obtener una alta probabilidad de ganar. Adem\u00e1s, atrapar a un BP astuto con tales manipulaciones es pr\u00e1cticamente imposible; se pueden usar nuevas direcciones cada vez y ganar poco a poco, sin levantar sospechas.<\/p>\n<p><\/p>\n<p>Por lo tanto, los m\u00e9todos que utilizan informaci\u00f3n del bloque no son adecuados como implementaci\u00f3n universal de PVRB. En una variante limitada, con restricciones en los tama\u00f1os de las apuestas, limitaciones en la cantidad de jugadores y\/o con registro KYC (para evitar que un solo jugador utilice m\u00faltiples direcciones), estos esquemas pueden funcionar para juegos peque\u00f1os, pero no m\u00e1s que eso.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-commit-reveal\">PVRB y commit-reveal.<\/h2>\n<p><\/p>\n<p>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\u00eda resultar algo m\u00e1s s\u00f3lido. Vamos a a\u00f1adir a los usuarios en este esquema \u2014 que tambi\u00e9n influyan en el azar: cualquier empleado de soporte t\u00e9cnico le dir\u00e1 que lo m\u00e1s aleatorio en los sistemas IT son las acciones de los usuarios \ud83d\ude42<\/p>\n<p><\/p>\n<p>Un esquema ingenuo, en el que los usuarios simplemente env\u00edan n\u00fameros aleatorios y el resultado se calcula como, por ejemplo, el hash de su suma, no es adecuado. En este caso, el \u00faltimo jugador que juega puede controlar el resultado eligiendo su propio n\u00famero aleatorio. Por lo tanto, se utiliza un patr\u00f3n muy com\u00fan llamado commit-reveal. Los participantes primero env\u00edan hashes de sus n\u00fameros aleatorios (commits) y luego revelan los n\u00fameros aleatorios (reveals). La fase de 'reveal' comienza solo despu\u00e9s de que se hayan recopilado los commits necesarios, por lo que los participantes pueden enviar exactamente el n\u00famero aleatorio del que enviaron anteriormente el hash. Ahora combinamos todo esto con los par\u00e1metros del bloque, preferiblemente tomados del futuro (el n\u00famero aleatorio solo se podr\u00e1 conocer en uno de los bloques futuros), \u00a1y voil\u00e0, el n\u00famero aleatorio est\u00e1 listo! Ahora cualquier jugador influye en el n\u00famero aleatorio resultante y puede 'vencer' a un BP malicioso, superponiendo su n\u00famero aleatorio con un n\u00famero desconocido de antemano... Tambi\u00e9n se puede agregar protecci\u00f3n 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\u00f3n: un dep\u00f3sito de seguridad que solo se devolver\u00e1 durante el procedimiento de reveal. En este caso, hacer un commit y no hacer un reveal no ser\u00e1 rentable.<\/p>\n<p><\/p>\n<p>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\u00e9n por cualquier participante del protocolo. Controlar el valor en s\u00ed todav\u00eda es posible, con menor variabilidad y a cambio de dinero, pero, como en el caso del minero, si los resultados del concurso son m\u00e1s valiosos que la tarifa de participaci\u00f3n en el protocolo PVRB, entonces el random-producer (RP) puede decidir si hace el reveal y todav\u00eda puede elegir entre al menos dos opciones de n\u00fameros aleatorios.<br \/>\nSin embargo, ahora hay la posibilidad de castigar a quienes hacen un commit y no hacen un reveal, y este esquema a\u00fan ser\u00e1 \u00fatil. Su simplicidad es una ventaja significativa: protocolos m\u00e1s complejos requieren c\u00e1lculos mucho m\u00e1s potentes.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-determinirovannye-podpisi\">PVRB y firmas deterministas.<\/h2>\n<p><\/p>\n<p>Hay otra forma de hacer que el RP proporcione un n\u00famero aleatorio pseudoaleatorio sobre el cual no podr\u00e1 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\u0421C, y firma un valor con su clave privada, en el caso de RSA solo obtendr\u00e1 UNA Y SOLA FIRMA, mientras que en el caso de ECS puede generar un n\u00famero arbitrario de firmas v\u00e1lidas diferentes. Esto se debe a que al crear una firma ECS se utiliza un n\u00famero aleatorio elegido por el firmante, el cual puede ser seleccionado libremente, lo que le da al firmante la opci\u00f3n 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\u00e9 firma tendr\u00e1 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\u00famero aleatorio anterior. En este esquema se ahorra bastante recurso, ya que las firmas son al mismo tiempo una confirmaci\u00f3n del comportamiento correcto seg\u00fan el protocolo y una fuente de aleatoriedad.<\/p>\n<p><\/p>\n<p>Sin embargo, incluso con firmas deterministas, el esquema sigue siendo vulnerable al problema del '\u00faltimo actor'. El \u00faltimo participante a\u00fan puede decidir si publica su firma o no, controlando as\u00ed el resultado. Se pueden mejorar los esquemas, a\u00f1adiendo hashes de bloques, realizando rondas para que el resultado no se pueda predecir por adelantado, pero todas estas t\u00e9cnicas, incluso considerando m\u00faltiples mejoras, a\u00fan 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\u00f3micas y temporales. Adem\u00e1s, el tama\u00f1o de las claves RSA (1024 y 2048 bits) es bastante grande, y el tama\u00f1o para transacciones en blockchain es un par\u00e1metro extremadamente importante. Aparentemente, no se podr\u00e1 resolver el problema de manera simple, sigamos adelante.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-secret-sharing-shemy\">Esquemas PVRB y de compartici\u00f3n secreta<\/h2>\n<p><\/p>\n<p>En criptograf\u00eda existen esquemas que permiten a la red acordar un solo valor de PVRB, siendo estos esquemas resistentes a cualquier acci\u00f3n maliciosa de parte de los participantes. Uno de los protocolos \u00fatiles 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\u00f3n son suficientes M partes de N, pudiendo ser cualquiera de esas M partes. Si lo explicamos de manera sencilla, al tener un gr\u00e1fico de una funci\u00f3n desconocida, los participantes intercambian puntos en el gr\u00e1fico, y despu\u00e9s de obtener M puntos, se puede recuperar toda la funci\u00f3n.<br \/>\nUna buena explicaci\u00f3n se encuentra en <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Shamir%27s_Secret_Sharing\">wiki<\/a><\/noindex> y para jugar con ello de manera pr\u00e1ctica, es \u00fatil usarlo en <noindex><a rel=\"nofollow\" href=\"http:\/\/point-at-infinity.org\/ssss\/demo.html\">demo<\/a><\/noindex> p\u00e1gina.<\/p>\n<p><\/p>\n<p>Si el esquema FSSS (Fiat-Shamir Secret Sharing) se aplicara de manera pura, ser\u00eda un PVRB invulnerable. En su forma m\u00e1s simple, el protocolo puede verse as\u00ed:<\/p>\n<p><\/p>\n<ul>\n<li>Cada participante genera su propio aleatorio y reparte participaciones de \u00e9l a los dem\u00e1s participantes.<\/li>\n<li>Cada participante revela su parte de los secretos de los dem\u00e1s participantes.<\/li>\n<li>Si un participante acumula m\u00e1s de M participaciones, se puede calcular el n\u00famero de ese participante, y ser\u00e1 \u00fanico, independientemente del conjunto de participantes que revelaron sus secretos.<\/li>\n<li>La combinaci\u00f3n de los aleatorios revelados es el PVRB buscado.<\/li>\n<\/ul>\n<p><\/p>\n<p>Aqu\u00ed, un participante individual ya no influye en los resultados del protocolo, excepto en los casos en que su participaci\u00f3n sea la \u00fanica que determine el umbral para revelar el aleatorio. Por lo tanto, este protocolo, dado que tiene la proporci\u00f3n necesaria de participantes siguiendo el protocolo y RP disponibles, cumple con los requisitos de resistencia criptogr\u00e1fica y es resistente al problema del \u201c\u00faltimo actor\u201d.<\/p>\n<p><\/p>\n<p>Este podr\u00eda ser el escenario ideal, el esquema de PVRB basado en el secreto compartido de Fiat-Shamir est\u00e1 descrito, por ejemplo, en <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2017\/216.pdf\">esta<\/a><\/noindex> el art\u00edculo. Pero, como se mencion\u00f3 anteriormente, si se intenta aplicarlo directamente en blockchain, surgen limitaciones t\u00e9cnicas. Aqu\u00ed tienes un ejemplo de la implementaci\u00f3n de un protocolo en un contrato inteligente de EOS y su parte m\u00e1s importante: la verificaci\u00f3n de la participaci\u00f3n publicada por el participante: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/eoscraper\/blob\/master\/Proof.hh#L23\">c\u00f3digo<\/a><\/noindex>. Por el c\u00f3digo, se puede ver que la validaci\u00f3n del proof requiere varias multiplicaciones escalares, y se utilizan n\u00fameros muy grandes. Es importante entender que en las blockchains la verificaci\u00f3n ocurre en el momento en que el bloque productor procesa la transacci\u00f3n, y cualquier participante debe poder verificar f\u00e1cilmente la correcta implementaci\u00f3n del protocolo, por lo que los requisitos de velocidad para la funci\u00f3n de verificaci\u00f3n son muy estrictos. En este caso, la alternativa result\u00f3 ser inviable, ya que la verificaci\u00f3n no cumpli\u00f3 con el l\u00edmite de tiempo de la transacci\u00f3n (0.5 seg).<\/p>\n<p><\/p>\n<p>La eficacia de la verificaci\u00f3n es uno de los requisitos m\u00e1s importantes para el uso de cualquier esquema criptogr\u00e1fico avanzado en blockchain. La creaci\u00f3n de proofs y la preparaci\u00f3n de mensajes son procedimientos que se pueden realizar off-chain en computadoras de alto rendimiento, pero la verificaci\u00f3n no se puede eludir, este es otro requisito importante para PVRB. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-threshold-signatures\">PVRB y firmas umbral<\/h2>\n<p><\/p>\n<p>Al familiarizarnos con el esquema de secret sharing, hemos abierto toda una clase de protocolos reunidos bajo la palabra clave \u201cthreshold\u201d. Cuando para revelar cierta informaci\u00f3n se requiere la participaci\u00f3n 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 \u201cthreshold\u201d. Estos permiten abordar el problema del \u201c\u00faltimo actor\u201d, ya que si un atacante no revela su parte del secreto, otro participante honesto lo har\u00e1. Estos esquemas permiten acordar un \u00fanico valor, incluso ante el sabotaje del protocolo por parte de algunos participantes. <\/p>\n<p><\/p>\n<p>La combinaci\u00f3n de firmas deterministas y esquemas de threshold ha permitido desarrollar un esquema muy conveniente y prometedor para la implementaci\u00f3n de PVRB: se trata de firmas umbral deterministas. Aqu\u00ed <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2002\/081.pdf\">Windows<\/a><\/noindex> sobre diversas aplicaciones de las firmas umbral, y aqu\u00ed hay otro buen ejemplo <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.dash.org\/secret-sharing-and-threshold-signatures-with-bls-954d1587b5f\">longread<\/a><\/noindex> de Dash. <\/p>\n<p><\/p>\n<p>El \u00faltimo art\u00edculo describe las firmas BLS (BLS se descompone como Boneh-Lynn-Shacham, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.iacr.org\/archive\/asiacrypt2001\/22480516.pdf\">aqu\u00ed<\/a><\/noindex> art\u00edculo ), que tienen una cualidad muy importante y extremadamente conveniente para los programadores: las claves p\u00fablicas, secretas y las firmas BLS pueden combinarse entre s\u00ed a trav\u00e9s de operaciones matem\u00e1ticas simples, manteniendo al mismo tiempo que sus combinaciones siguen siendo claves y firmas v\u00e1lidas, lo que permite agregar f\u00e1cilmente muchas firmas en una sola y muchas claves p\u00fablicas en una. Tambi\u00e9n poseen determinismo y, con los mismos datos de entrada, producen el mismo resultado. Gracias a esta cualidad, las combinaciones de firmas BLS en s\u00ed mismas son claves v\u00e1lidas, lo que permite implementar una variante donde M de N participantes producen una \u00fanica firma, que es determinada, p\u00fablicamente verificable e impredecible hasta que sea revelada por el M-\u00e9simo participante.<\/p>\n<p><\/p>\n<p>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\u00e1ficas de las firmas BLS cumplen con los requisitos de calidad del aleatorio, la parte de umbral protege contra el \u201c\u00faltimo actor\u201d, y la \u00fanica combinabilidad de las claves permite implementar muchos algoritmos interesantes que, por ejemplo, permiten agregar de manera eficiente los mensajes del protocolo.<\/p>\n<p><\/p>\n<p>As\u00ed que, si est\u00e1s 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 (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/random-beacon\">aqu\u00ed<\/a><\/noindex> benchmark, implementando el esquema, y <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/vss\/blob\/master\/docs\/index.md\">aqu\u00ed<\/a><\/noindex> un ejemplo de implementaci\u00f3n de compartici\u00f3n secreta verificable), o Keep.network (aqu\u00ed su random beacon <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-yellowpaper\">yellowpaper<\/a><\/noindex>, pero <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-box\">ejemplo<\/a><\/noindex> smart contract que soporta el protocolo).<\/p>\n<p><\/p>\n<h2 id=\"implementaciya-pvrb\">Implementaci\u00f3n de PVRB<\/h2>\n<p><\/p>\n<p>Lamentablemente, a\u00fan 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\u00e1n listos, aplicarlos t\u00e9cnicamente a soluciones existentes no es f\u00e1cil. Para sistemas centralizados, PVRB no tiene sentido, y los descentralizados est\u00e1n estrictamente limitados en todos los recursos computacionales: CPU, memoria, almacenamiento, I\/O. El dise\u00f1o de PVRB consiste en combinar diferentes protocolos para crear algo que cumpla con todos los requisitos, al menos para alg\u00fan blockchain viable. Un protocolo calcula de manera m\u00e1s eficiente, pero requiere m\u00e1s mensajes entre los RP, mientras que otro requiere muy pocos mensajes, pero la generaci\u00f3n de una prueba puede tomar decenas de minutos o incluso horas.<\/p>\n<p><\/p>\n<p>Enumerar\u00e9 los factores que deber\u00e1 considerar al elegir un PVRB de calidad:<\/p>\n<p><\/p>\n<ul>\n<li><em>Resistencia criptogr\u00e1fica<\/em>. Su PVRB debe ser estrictamente inalterable, sin la posibilidad de controlar un solo bit. En algunos esquemas, esto no es as\u00ed, por lo que debe consultar a un cript\u00f3grafo.<\/li>\n<li><em>Problema del \u201c\u00faltimo actor\u201d<\/em>. Su PVRB debe ser resistente a ataques en los que un atacante que controla uno o varios RP puede elegir entre dos resultados.<\/li>\n<li><em>Problema del sabotaje del protocolo<\/em>. 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.<\/li>\n<li><em>Problema de la cantidad de mensajes<\/em>. Sus RP deben enviar al blockchain el m\u00ednimo de mensajes y evitar al m\u00e1ximo acciones s\u00edncronas, como situaciones de \u201che enviado cierta informaci\u00f3n, estoy esperando una respuesta de un participante espec\u00edfico\u201d. En redes p2p, especialmente geogr\u00e1ficamente dispersas, no se debe contar con una respuesta r\u00e1pida.<\/li>\n<li><em>Problema de la complejidad computacional<\/em>. La verificaci\u00f3n 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\u00f3n se hace mediante un contrato inteligente, entonces los requisitos de velocidad son muy estrictos.<\/li>\n<li><em>Problema de disponibilidad y liveness<\/em>. 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.<\/li>\n<li><em>Problema de la configuraci\u00f3n confiable y la distribuci\u00f3n inicial de claves.<\/em>. Si su PVRB utiliza una configuraci\u00f3n primaria del protocolo, esa es una historia separada y seria. Aqu\u00ed est\u00e1 <noindex><a rel=\"nofollow\" href=\"https:\/\/z.cash\/ru\/blog\/the-design-of-the-ceremony\/\">ejemplo<\/a><\/noindex>. Si los participantes deben intercambiar sus claves antes de que inicie el protocolo, tambi\u00e9n es un problema si la composici\u00f3n de los participantes cambia<\/li>\n<li><em>Problemas de desarrollo<\/em>. La disponibilidad de bibliotecas en los lenguajes necesarios, su seguridad y rendimiento, la publicidad, pruebas complejas, etc.<\/li>\n<\/ul>\n<p><\/p>\n<p>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\u00e1 el umbral. Esto significa que al menos una ronda de intercambio en una red descentralizada tendr\u00e1 que esperarse y, considerando que el random generado, por ejemplo, es necesario en juegos, pr\u00e1cticamente 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\u00e1s manejable que los anteriores, pero a\u00fan as\u00ed requiere el desarrollo de un procedimiento separado para la formaci\u00f3n de grupos umbral, que deber\u00e1 ser protegido econ\u00f3micamente, mediante dep\u00f3sitos y la reducci\u00f3n de fondos (slashing) de los participantes que no sigan el protocolo. Adem\u00e1s, la verificaci\u00f3n BLS con un nivel de seguridad aceptable simplemente no encaja, por ejemplo, en una transacci\u00f3n est\u00e1ndar de EOS o Ethereum: simplemente no hay tiempo suficiente para la verificaci\u00f3n. El c\u00f3digo de los contratos es WebAssembly o EVM, ejecutado por una m\u00e1quina virtual. Las funciones criptogr\u00e1ficas no se implementan de forma nativa (por ahora), y funcionan varias veces m\u00e1s lentas que las bibliotecas criptogr\u00e1ficas est\u00e1ndar. 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\u00e1s que la firma est\u00e1ndar de una transacci\u00f3n en Bitcoin y Ethereum.<\/p>\n<p><\/p>\n<p>Tambi\u00e9n juega un papel la disponibilidad de implementaciones en diferentes lenguajes de programaci\u00f3n, que son escasas, especialmente para nuevos protocolos. La opci\u00f3n de integraci\u00f3n en el consenso requiere escribir el protocolo en el lenguaje de la plataforma, as\u00ed que se tendr\u00e1 que buscar c\u00f3digo en Go para geth, en Rust para Parity, en C++ para EOS. El c\u00f3digo en JavaScript habr\u00e1 que buscarlo por todos, y dado que JavaScript y la criptograf\u00eda no son amigos cercanos, ser\u00e1 \u00fatil WebAssembly, que ahora definitivamente aspira a ser el pr\u00f3ximo est\u00e1ndar importante de Internet.<\/p>\n<p><\/p>\n<h2 id=\"zaklyuchenie\">Conclusi\u00f3n<\/h2>\n<p><\/p>\n<p>Espero que en el anterior <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/448330\/\">el art\u00edculo<\/a><\/noindex> He logrado convencerte de que la generaci\u00f3n de n\u00fameros aleatorios en la cadena de bloques es cr\u00edticamente importante para muchos aspectos de la vida de las redes descentralizadas, y en este art\u00edculo he demostrado que esta tarea es extremadamente ambiciosa y dif\u00edcil, pero ya existen buenas soluciones. En general, el dise\u00f1o final del protocolo solo es posible despu\u00e9s de llevar a cabo pruebas masivas que tengan en cuenta todos los aspectos, desde la configuraci\u00f3n hasta la simulaci\u00f3n de fallos, por lo que es poco probable que encuentres recetas listas en los whitepapers de los equipos o en los art\u00edculos, y tampoco nos atreveremos a escribir en el pr\u00f3ximo a\u00f1o o dos 'hace esto, as\u00ed es definitivamente correcto'. <\/p>\n<p><\/p>\n<p>Por ahora, para nuestro PVRB en la cadena de bloques en desarrollo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/haya\">Haya<\/a><\/noindex>, hemos decidido aplicar firmas BLS de umbral, planeamos implementar PVRB a nivel de consenso, ya que la verificaci\u00f3n en contratos inteligentes con un nivel aceptable de seguridad a\u00fan 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\u00f3n de aleatoriedad de alta frecuencia mediante firmas BLS de umbral determin\u00edsticas, y quiz\u00e1s nos limitemos a uno solo de los esquemas. Decir de antemano cu\u00e1l ser\u00e1 el protocolo, lamentablemente, es imposible, lo que alegra es que, al igual que en la ciencia, en los problemas de ingenier\u00eda, un resultado negativo tambi\u00e9n es un resultado, y cada nuevo intento de resolver el problema es un nuevo escal\u00f3n para la investigaci\u00f3n de todos los que est\u00e1n involucrados en el tema. Para satisfacer las demandas del negocio, estamos resolviendo una tarea pr\u00e1ctica espec\u00edfica: proporcionar a las aplicaciones de juego una fuente confiable de entrop\u00eda, por lo que tambi\u00e9n tenemos que prestar atenci\u00f3n a la propia cadena de bloques, en particular a cuestiones de finalizaci\u00f3n de la cadena y gobernanza de la red. <\/p>\n<p><\/p>\n<p>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\u00faltiples auditor\u00edas, cargas y, por supuesto, ataques reales, el n\u00famero de posibles caminos confirma que la soluci\u00f3n existe y que alguno de estos algoritmos, al final, resolver\u00e1 el problema. Estaremos encantados de compartir los resultados y agradecemos a otros equipos que tambi\u00e9n est\u00e1n trabajando en este tema por los art\u00edculos y el c\u00f3digo que permiten a los ingenieros no caer dos veces en las mismas trampas. <\/p>\n<p><\/p>\n<p>As\u00ed que, al encontrarte con un programador que dise\u00f1a un random descentralizado, s\u00e9 cauteloso y considerado, y ofrece apoyo psicol\u00f3gico si es necesario \ud83d\ude42<\/p>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/452340\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number! } \u041a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0441 \u043a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u0435\u0439 \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u0441\u0442\u043e\u0439\u043a\u043e\u0433\u043e \u0448\u0438\u0444\u0440\u0430 \u0438\u0437 \u043a\u0440\u0438\u043f\u0442\u043e\u0433\u0440\u0430\u0444\u0438\u0438, \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u201cPublicly Verifiable Random Beacon\u201d (\u0434\u0430\u043b\u0435\u0435 PVRB) \u043b\u0438\u0448\u044c \u043f\u044b\u0442\u0430\u044e\u0442\u0441\u044f \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u043f\u0440\u0438\u0431\u043b\u0438\u0437\u0438\u0442\u044c\u0441\u044f \u043a \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u0435, \u0442.\u043a. \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0445 \u0441\u0435\u0442\u044f\u0445 \u0432 \u0447\u0438\u0441\u0442\u043e\u043c \u0432\u0438\u0434\u0435 \u043e\u043d\u0430 \u043d\u0435\u043f\u0440\u0438\u043c\u0435\u043d\u0438\u043c\u0430: \u0434\u043e\u0433\u043e\u0432\u0430\u0440\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u043d\u0430\u0434\u043e \u0441\u0442\u0440\u043e\u0433\u043e \u043e\u0431 \u043e\u0434\u043d\u043e\u043c \u0431\u0438\u0442\u0435, \u0440\u0430\u0443\u043d\u0434\u043e\u0432 \u0434\u043e\u043b\u0436\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33888","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47N\u00fameros aleatorios y redes descentralizadas: implementaciones | ProHoster","description":"Introducci\u00f3n function getAbsolutelyRandomNumer() { return 4; \/\/ \u00a1devuelve un n\u00famero absolutamente aleatorio!","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:55:15+00:00","article:modified_time":"2019-10-31T18:55:15+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33888","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 17:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:31:23","updated":"2026-01-21 17:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/33888","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=33888"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/33888\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=33888"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=33888"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=33888"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}