{"id":95468,"date":"2020-09-29T19:42:29","date_gmt":"2020-09-29T17:42:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1"},"modified":"2020-09-29T19:42:29","modified_gmt":"2020-09-29T17:42:29","slug":"mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","title":{"rendered":"\u00bfSe pueden generar n\u00fameros aleatorios si no confiamos los unos en los otros? Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola, Habr!<\/p>\n

En este art\u00edculo, hablar\u00e9 sobre la generaci\u00f3n de n\u00fameros pseudoaleatorios entre participantes que no conf\u00edan entre s\u00ed. Como veremos a continuaci\u00f3n, implementar un generador de n\u00fameros \u201ccasi\u201d bueno es bastante simple, pero uno muy bueno es complicado.<\/p>\n

\u00bfPor qu\u00e9 generar n\u00fameros aleatorios para participantes que no conf\u00edan entre s\u00ed? Una de las \u00e1reas de aplicaci\u00f3n es en las aplicaciones descentralizadas. Por ejemplo, una aplicaci\u00f3n que acepta una apuesta de un participante y, con una probabilidad del 49%, duplica la cantidad o se queda con un 51%, solo funcionar\u00e1 si puede obtener un n\u00famero aleatorio de manera imparcial. Si un atacante puede influir en el resultado del generador de n\u00fameros aleatorios y aumentar incluso levemente sus posibilidades de recibir un pago en la aplicaci\u00f3n, podr\u00eda vaciarla f\u00e1cilmente.<\/p>\n

Cuando desarrollamos un protocolo distribuido para la generaci\u00f3n de n\u00fameros aleatorios, queremos que tenga tres propiedades:<\/p>\n

    \n
  1. \n

    Debe ser imparcial. En otras palabras, ning\u00fan participante debe influir en el resultado del generador de n\u00fameros aleatorios de ninguna manera.<\/p>\n<\/li>\n

  2. \n

    Debe ser impredecible. En otras palabras, ning\u00fan participante debe ser capaz de anticipar qu\u00e9 n\u00famero ser\u00e1 generado (o deducir alguna de sus propiedades) antes de que sea generado.<\/p>\n<\/li>\n

  3. \n

    El protocolo debe ser viable, es decir, resistente a que un porcentaje de los participantes se desconecte de la red o intente detener el protocolo de forma intencionada.<\/p>\n<\/li>\n<\/ol>\n

    En este art\u00edculo, revisaremos dos enfoques: RANDAO + VDF y un enfoque basado en c\u00f3digos borrables. En la siguiente parte, analizaremos a fondo el enfoque basado en firmas umbrales.<\/p>\n

    Pero primero, descompongamos un algoritmo simple y com\u00fanmente utilizado, que es viable, impredecible, pero sesgado.<\/p>\n

    RANDAO<\/h3>\n

    RANDAO es un enfoque muy simple y, por lo tanto, bastante utilizado para obtener aleatoriedad. Todos los participantes de la red primero eligen localmente un n\u00famero pseudoaleatorio, luego cada participante env\u00eda el hash del n\u00famero elegido. A continuaci\u00f3n, los participantes revelan por turnos sus n\u00fameros elegidos y realizan la operaci\u00f3n XOR sobre los n\u00fameros revelados, y el resultado de esta operaci\u00f3n se convierte en el resultado del protocolo.<\/p>\n

    El paso de publicar los hash antes de revelar los n\u00fameros es necesario para que un atacante no pueda elegir su n\u00famero despu\u00e9s de haber visto los n\u00fameros de los dem\u00e1s participantes. Esto le permitir\u00eda, de hecho, determinar de manera unilateral el resultado del generador de n\u00fameros aleatorios.<\/p>\n

    A lo largo del protocolo, los participantes deben llegar a un consenso dos veces (es decir, acuerdo): cu\u00e1ndo empezar a revelar los n\u00fameros elegidos y, por lo tanto, dejar de aceptar los hash, y cu\u00e1ndo finalizar la aceptaci\u00f3n de los n\u00fameros elegidos y calcular el n\u00famero aleatorio resultante. Tomar tales decisiones entre participantes que no conf\u00edan unos en otros es en s\u00ed mismo una tarea complicada, y volveremos a ello en futuros art\u00edculos; en este art\u00edculo asumiremos que dicho algoritmo de consenso est\u00e1 disponible para nosotros.<\/p>\n

    \u00bfCu\u00e1les de las propiedades que describimos anteriormente tiene RANDAO? Es impredecible, tiene la misma viabilidad que el protocolo de consenso subyacente, pero es sesgado. En particular, un atacante puede observar la red y, despu\u00e9s de que otros participantes revelen sus n\u00fameros, puede calcular su XOR y decidir si revelar o no su n\u00famero para influir en el resultado. Aunque esto no permite que el atacante determine unilateralmente el resultado del generador de n\u00fameros aleatorios, a\u00fan le proporciona 1 bit de influencia. Y si los atacantes controlan m\u00faltiples participantes, el n\u00famero de bits bajo su control ser\u00e1 igual al n\u00famero de participantes que controlan.<\/p>\n

    \"\u00bfSe<\/p>\n

    La influencia de los atacantes se puede reducir significativamente si se exige que los participantes revelen los n\u00fameros en orden. Entonces, un atacante solo podr\u00e1 influir en el resultado si se revela al final. Aunque la influencia es considerablemente menor, el algoritmo sigue siendo sesgado.<\/p>\n

    RANDAO + VDF<\/h3>\n

    Una de las formas de hacer que RANDAO sea imparcial es la siguiente: una vez que todos los n\u00fameros han sido revelados y se ha calculado el XOR, el resultado se introduce en una funci\u00f3n que toma mucho tiempo para calcular, pero permite verificar la correcci\u00f3n del c\u00e1lculo de forma muy r\u00e1pida.<\/p>\n

    (vdf_output, vdf_proof) = VDF_compute(input) \/\/ esto es muy lento\ncorrect = VDF_verify(input, vdf_output, vdf_proof) \/\/ esto es muy r\u00e1pido<\/code><\/pre>\n
    Esta funci\u00f3n se llama Verifiable Delay Function, o VDF. Si el tiempo de c\u00e1lculo del resultado final es mayor que la fase de revelaci\u00f3n de n\u00fameros, entonces un atacante no podr\u00e1 predecir el efecto de mostrar o ocultar su n\u00famero, y por lo tanto perder\u00e1 la capacidad de influir en el resultado.<\/p>\n
    Desarrollar un buen VDF es extremadamente complicado. Recientemente se han producido algunos avances, como este<\/u><\/a><\/noindex> y este,<\/u><\/a><\/noindex> que han hecho que los VDF sean m\u00e1s aplicables en la pr\u00e1ctica, y Ethereum 2.0 planea a largo plazo utilizar RANDAO con VDF como fuente de n\u00fameros aleatorios. Adem\u00e1s de ser impredecible y no sesgado, este enfoque tiene la ventaja adicional de ser viable siempre que al menos dos participantes est\u00e9n disponibles en la red (asumiendo que el protocolo de consenso utilizado es viable con tan pocos participantes).<\/p>\n
    La mayor dificultad de este enfoque radica en configurar el VDF de tal manera que ni siquiera un participante con hardware especializado muy costoso pueda calcular el VDF antes de que finalice la fase de revelaci\u00f3n. Idealmente, el algoritmo deber\u00eda tener un margen de seguridad significativo, digamos, de 10x. En la imagen de abajo se muestra un ataque de un participante que tiene un ASIC especializado que le permite ejecutar el VDF m\u00e1s r\u00e1pido que el tiempo asignado para la revelaci\u00f3n de la confirmaci\u00f3n de RANDAO. Este participante a\u00fan puede calcular el resultado final usando o no usando su n\u00famero, y despu\u00e9s de eso, bas\u00e1ndose en los c\u00e1lculos, decidir si mostrarlo o no.<\/p>\n
    \"\u00bfSe<\/p>\n
    Para la familia de VDF mencionada anteriormente, el rendimiento de un ASIC especializado puede ser m\u00e1s de 100 veces superior al de hardware convencional. As\u00ed, si la fase de revelaci\u00f3n dura 10 segundos, el VDF calculado en un ASIC as\u00ed deber\u00eda tardar m\u00e1s de 100 segundos para tener un margen de seguridad de 10 veces, y por lo tanto, el mismo VDF calculado en hardware convencional deber\u00eda tardar 100 x 100 segundos = ~ 3 horas.<\/p>\n
    La Fundaci\u00f3n Ethereum planea abordar este problema creando sus propios ASIC gratuitos y p\u00fablicos. Una vez que esto suceda, todos los dem\u00e1s protocolos tambi\u00e9n podr\u00e1n beneficiarse de esta tecnolog\u00eda, pero hasta entonces, el enfoque RANDAO + VDF no ser\u00e1 tan viable para los protocolos que no pueden invertir en el desarrollo de sus propios ASIC.<\/p>\n
    Se ha recopilado una gran cantidad de art\u00edculos, videos e informaci\u00f3n sobre VDF en este sitio<\/u><\/a><\/noindex>.<\/p>\n
    Usamos c\u00f3digos que borran<\/h3>\n
    En esta secci\u00f3n, analizaremos el protocolo de generaci\u00f3n de n\u00fameros aleatorios que utiliza c\u00f3digos que borran<\/a><\/noindex>. Puede soportar hasta \u2153 de actores maliciosos, permaneciendo viable, y permite la existencia de hasta \u2154 de actores maliciosos antes de que puedan predecir o influir en el resultado.<\/p>\n
    La idea principal del protocolo es la siguiente. Para simplificar, supongamos que hay exactamente 100 participantes. Supongamos tambi\u00e9n que todos los participantes tienen localmente una cierta clave privada, y las claves p\u00fablicas de todos los participantes son conocidas por todos los participantes:<\/p>\n
      \n
    1. \n
      Cada participante genera localmente una larga cadena, la divide en 67 partes, crea c\u00f3digos borrables para obtener 100 acciones, de modo que cualquier conjunto de 67 sea suficiente para reconstruir la cadena, asigna cada una de las 100 partes a uno de los participantes y las cifra con la clave p\u00fablica del mismo participante. Luego se publican todas las partes codificadas.<\/p>\n<\/li>\n
    2. \n
      Los participantes utilizan alg\u00fan consenso para llegar a un acuerdo sobre los conjuntos codificados de 67 participantes espec\u00edficos.<\/p>\n<\/li>\n
    3. \n
      Una vez alcanzado el consenso, cada participante toma las partes codificadas en cada uno de los 67 conjuntos, cifradas con su clave p\u00fablica, descifra todas esas partes y publica todas esas partes descifradas.<\/p>\n<\/li>\n
    4. \n
      Una vez que 67 participantes han realizado el paso (3), todos los conjuntos acordados pueden ser completamente decodificados y restaurados gracias a las propiedades de los c\u00f3digos borrables, y el n\u00famero final puede ser obtenido como el XOR de las cadenas iniciales de las que los participantes comenzaron en (1).<\/p>\n<\/li>\n<\/ol>\n
      \"\u00bfSe<\/p>\n
      Se puede demostrar que este protocolo es imparcial e impredecible. El n\u00famero aleatorio resultante se define despu\u00e9s de alcanzar el consenso, pero no se conoce hasta que \u2154 de los participantes decodifican las partes cifradas con su clave p\u00fablica. As\u00ed, el n\u00famero aleatorio se define antes de que se publique la informaci\u00f3n necesaria para su recuperaci\u00f3n.<\/p>\n
      \u00bfQu\u00e9 ocurre si en el paso (1) uno de los participantes envi\u00f3 a los dem\u00e1s participantes partes codificadas que no son un c\u00f3digo de borrado v\u00e1lido para alg\u00fan string? Sin cambios adicionales, diferentes participantes no podr\u00e1n recuperar el string en absoluto, o recuperar\u00e1n strings diferentes, lo que provocar\u00e1 que diferentes participantes obtengan distintos n\u00fameros aleatorios. Para prevenir esto, se puede hacer lo siguiente: cada participante, adem\u00e1s de las partes codificadas, tambi\u00e9n calcula el \u00e1rbol de Merkle<\/a><\/noindex> de todas esas partes, y env\u00eda a cada participante tanto la parte codificada como la ra\u00edz del \u00e1rbol de Merkle y la prueba de inclusi\u00f3n de la parte en el \u00e1rbol de Merkle. En el consenso del paso (2), los participantes no solo acuerdan sobre un conjunto de muchas partes, sino sobre muchas ra\u00edces concretas de esos \u00e1rboles (si alg\u00fan participante se desv\u00eda del protocolo y env\u00eda diferentes ra\u00edces del \u00e1rbol de Merkle a diferentes participantes, y se muestran dos de esas ra\u00edces durante el consenso, su string no se incluye en el conjunto resultante). Como resultado del consenso, tendremos 67 strings codificados y sus correspondientes ra\u00edces del \u00e1rbol de Merkle, de modo que hay al menos 67 participantes (no necesariamente los mismos que propusieron las strings correspondientes), que poseen para cada uno de los 67 strings un mensaje con la parte del c\u00f3digo de borrado y la prueba de inclusi\u00f3n de su parte en el \u00e1rbol de Merkle correspondiente.<\/p>\n
      Cuando en el paso (4) un participante descodifica 67 partes para alg\u00fan string e intenta reconstruir el string original, se puede dar uno de los siguientes casos:<\/p>\n
        \n
      1. \n
        El string se reconstruye, y si se vuelve a codificar con c\u00f3digos de borrado y se calcula el \u00e1rbol de Merkle para las partes contadas localmente, la ra\u00edz coincide con la que se acord\u00f3 en el consenso.<\/p>\n<\/li>\n
      2. \n
        El string se reconstruye, pero la ra\u00edz calculada localmente no coincide con la que se acord\u00f3 en el consenso.<\/p>\n<\/li>\n
      3. \n
        El string no se reconstruye.<\/p>\n<\/li>\n<\/ol>\n
        Es f\u00e1cil demostrar que si al menos para un participante se presenta la opci\u00f3n (1), entonces para todos los participantes se presentar\u00e1 la opci\u00f3n (1), y viceversa, si al menos para un participante se presenta la opci\u00f3n (2) o (3), entonces para todos los participantes se presentar\u00e1 la opci\u00f3n (2) o (3). As\u00ed, para cada fila en el conjunto, o todos los participantes la restaurar\u00e1n con \u00e9xito, o todos los participantes no podr\u00e1n restaurarla. Entonces, el n\u00famero aleatorio resultante es el XOR solo de aquellas filas que los participantes pudieron restaurar.<\/p>\n
        Firmas umbral<\/h3>\n
        Otro enfoque de la aleatoriedad implica el uso de las llamadas firmas umbral BLS. El generador de n\u00fameros aleatorios basado en firmas umbral tiene exactamente las mismas garant\u00edas que el algoritmo descrito anteriormente basado en c\u00f3digos borrables, pero tiene una asint\u00f3tica significativamente menor en la cantidad de mensajes enviados a trav\u00e9s de la red por cada n\u00famero generado.<\/p>\n
        Las firmas BLS son una construcci\u00f3n que permite a varios participantes crear una \u00fanica firma compartida para un mensaje. Estas firmas se utilizan frecuentemente para ahorrar espacio y ancho de banda, ya que no requieren el env\u00edo de m\u00faltiples firmas. <\/p>\n
        Un uso frecuente de las firmas BLS en protocolos de blockchain, adem\u00e1s de la generaci\u00f3n de n\u00fameros aleatorios, es la firma de bloques en protocolos BFT. Por ejemplo, 100 participantes crean bloques, y un bloque se considera final si 67 de ellos lo firman. Todos pueden presentar sus partes de la firma BLS y usar alg\u00fan algoritmo de consenso para acordar 67 de ellas, y luego combinarlas en una \u00fanica firma BLS. Cualquier conjunto de 67 (o m\u00e1s) partes puede ser utilizado para crear la firma final, que depender\u00e1 de qu\u00e9 67 firmas espec\u00edficas se hayan combinado, y por lo tanto puede diferir; sin embargo, a pesar de que diferentes elecciones de 67 participantes crear\u00e1n diferentes firmas, cualquier firma de este tipo ser\u00e1 una firma v\u00e1lida para el bloque. Los otros participantes solo necesitan recibir a trav\u00e9s de la red y verificar una \u00fanica firma por bloque, en lugar de 67, lo que reduce considerablemente la carga en la red.<\/p>\n
        Resulta que si las claves privadas utilizadas por los participantes se generan de cierta manera, entonces, independientemente de cu\u00e1ntas 67 firmas (o m\u00e1s, pero nunca menos) se agreguen, la firma resultante ser\u00e1 la misma. Esto puede ser utilizado como una fuente de aleatoriedad: los participantes primero acuerdan un mensaje espec\u00edfico que firmar\u00e1n (esto puede ser el resultado de RANDAO o simplemente el hash del \u00faltimo bloque, en realidad no tiene importancia, siempre que cambie cada vez y sea consensuado), y crean para ello una firma BLS. El resultado de la generaci\u00f3n ser\u00e1 impredecible hasta que los 67 participantes proporcionen sus partes, y despu\u00e9s de eso, la salida ya est\u00e1 predefinida y no puede depender de las acciones de ning\u00fan participante.<\/p>\n
        Este enfoque a la aleatoriedad es viable si al menos \u2154 de los participantes est\u00e1n en l\u00ednea y siguen el protocolo, y es imparcial e impredecible mientras al menos \u2153 de los participantes sigan el protocolo. Es importante se\u00f1alar que un atacante que controle m\u00e1s de \u2153 pero menos de \u2154 de los participantes puede detener el protocolo, pero no puede predecir o influir en su salida.<\/p>\n
        Las firmas umbral en s\u00ed mismas son un tema muy interesante. En la segunda parte del art\u00edculo, analizaremos en detalle c\u00f3mo funcionan y c\u00f3mo deben generarse las claves de los participantes para que las firmas umbral puedan utilizarse como generador de n\u00fameros aleatorios.<\/p>\n
        En conclusi\u00f3n<\/h3>\n
        Este art\u00edculo es el primero en una serie de art\u00edculos t\u00e9cnicos en el blog NEAR<\/a><\/noindex>. NEAR es un protocolo de blockchain y una plataforma para el desarrollo de aplicaciones descentralizadas con \u00e9nfasis en la facilidad de desarrollo y la simplicidad de uso para los usuarios finales.<\/p>\n
        El c\u00f3digo del protocolo es de c\u00f3digo abierto, nuestra implementaci\u00f3n est\u00e1 escrita en Rust y se puede encontrar aqu\u00ed<\/a><\/noindex>.<\/p>\n
        Puedes ver c\u00f3mo es el desarrollo en NEAR y experimentar en un IDE en l\u00ednea aqu\u00ed<\/a><\/noindex>.<\/p>\n
        Puedes seguir todas las noticias en ruso en el grupo de Telegram<\/a><\/noindex> y en el grupo en VKontakte<\/a><\/noindex>, y en ingl\u00e9s en el oficial twitter<\/a><\/noindex>.<\/p>\n
        \u00a1Hasta pronto!<\/p>\n
        Fuente: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
        \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043f\u0440\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u043f\u0441\u0435\u0432\u0434\u043e-\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0442 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443. \u041a\u0430\u043a \u043c\u044b \u0443\u0432\u0438\u0434\u0438\u043c \u043d\u0438\u0436\u0435, \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u201c\u043f\u043e\u0447\u0442\u0438\u201d \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u0433\u0435\u043d\u0435\u0440\u0430\u0442\u043e\u0440 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043f\u0440\u043e\u0441\u0442\u043e, \u0430 \u0432\u043e\u0442 \u043e\u0447\u0435\u043d\u044c \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u2013 \u0441\u043b\u043e\u0436\u043d\u043e. \u0417\u0430\u0447\u0435\u043c \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0443\u0436\u043d\u043e \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c, \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0449\u0438\u043c \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443? \u041e\u0434\u043d\u0430 \u0438\u0437 \u043e\u0431\u043b\u0430\u0441\u0442\u0435\u0439 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f — \u044d\u0442\u043e \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u043a\u043e\u0442\u043e\u0440\u043e\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":95469,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-95468","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00bfEs posible generar n\u00fameros aleatorios si no confiamos unos en otros? Parte 1 | ProHoster","description":"\u00a1Hola, Habr! En este art\u00edculo, hablar\u00e9 sobre la generaci\u00f3n de n\u00fameros pseudo-aleatorios entre participantes que no conf\u00edan entre s\u00ed.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","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\u041c\u043e\u0436\u043d\u043e \u043b\u0438 \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430, \u0435\u0441\u043b\u0438 \u043c\u044b \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u0435\u043c \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443? \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043f\u0440\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u043f\u0441\u0435\u0432\u0434\u043e-\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0442 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","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":"2020-09-29T17:42:29+00:00","article:modified_time":"2020-09-29T17:42:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"95468","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:05:29","updated":"2022-09-28 01:55:15","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\/95468","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=95468"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/95468\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/95469"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=95468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=95468"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=95468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}