{"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\/pt\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","title":{"rendered":"\u00c9 poss\u00edvel gerar n\u00fameros aleat\u00f3rios se n\u00e3o confiamos uns nos outros? Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1, Habr!<\/p>\n

Neste artigo, falarei sobre a gera\u00e7\u00e3o de n\u00fameros pseudo-aleat\u00f3rios entre participantes que n\u00e3o confiam uns nos outros. Como veremos a seguir, implementar um gerador \"quase\" bom \u00e9 bastante simples, enquanto um muito bom \u00e9 complexo.<\/p>\n

Por que gerar n\u00fameros aleat\u00f3rios para participantes que n\u00e3o confiam uns nos outros? Uma das aplica\u00e7\u00f5es \u00e9 em aplicativos descentralizados. Por exemplo, um aplicativo que aceita uma aposta de um participante e duplica a quantia com 49% de probabilidade ou a retira com 51%, funcionar\u00e1 apenas se conseguir obter um n\u00famero aleat\u00f3rio de forma imparcial. Se um invasor puder influenciar o resultado do gerador de n\u00fameros aleat\u00f3rios e at\u00e9 mesmo aumentar levemente sua chance de receber o pagamento no aplicativo, ele facilmente o esvaziar\u00e1.<\/p>\n

Quando desenvolvemos um protocolo distribu\u00eddo para gera\u00e7\u00e3o de n\u00fameros aleat\u00f3rios, queremos que ele possua tr\u00eas propriedades:<\/p>\n

    \n
  1. \n

    Ele deve ser imparcial. Em outras palavras, nenhum participante deve de forma alguma influenciar o resultado do gerador de n\u00fameros aleat\u00f3rios.<\/p>\n<\/li>\n

  2. \n

    Ele deve ser imprevis\u00edvel. Em outras palavras, nenhum participante deve ter a capacidade de prever qual n\u00famero ser\u00e1 gerado (ou extrair quaisquer de suas propriedades) antes de ser gerado.<\/p>\n<\/li>\n

  3. \n

    O protocolo deve ser vi\u00e1vel, ou seja, resistente ao fato de que uma certa porcentagem de participantes desconectar\u00e1 da rede ou tentar\u00e1 parar o protocolo intencionalmente.<\/p>\n<\/li>\n<\/ol>\n

    Neste artigo, analisaremos duas abordagens: RANDAO + VDF e uma abordagem baseada em c\u00f3digos de apagamento. Na pr\u00f3xima parte, examinaremos em detalhes a abordagem baseada em assinaturas de limite.<\/p>\n

    Mas, primeiro, vamos analisar um algoritmo simples e frequentemente utilizado que \u00e9 vi\u00e1vel, imprevis\u00edvel, mas tendencioso.<\/p>\n

    RANDAO<\/h3>\n

    RANDAO \u00e9 uma abordagem muito simples e, portanto, bastante comum para obter aleatoriedade. Todos os participantes da rede primeiro escolhem localmente um n\u00famero pseudoaleat\u00f3rio, em seguida, cada participante envia o hash do n\u00famero escolhido. Depois, os participantes revelam suas escolhas em ordem e realizam uma opera\u00e7\u00e3o XOR sobre os n\u00fameros revelados, e o resultado dessa opera\u00e7\u00e3o se torna o resultado do protocolo.<\/p>\n

    A etapa de publica\u00e7\u00e3o de hashes antes de revelar os n\u00fameros \u00e9 necess\u00e1ria para que um invasor n\u00e3o possa escolher seu n\u00famero ap\u00f3s ver os n\u00fameros dos outros participantes. Isso lhe permitiria, de fato, determinar unilateralmente a sa\u00edda do gerador de n\u00fameros aleat\u00f3rios.<\/p>\n

    Durante o protocolo, os participantes precisam concordar duas vezes em uma solu\u00e7\u00e3o comum (o chamado consenso): quando come\u00e7ar a revelar os n\u00fameros escolhidos e, consequentemente, parar de aceitar hashes, e quando terminar de aceitar os n\u00fameros escolhidos e calcular o n\u00famero aleat\u00f3rio resultante. Tomar tais decis\u00f5es entre participantes que n\u00e3o confiam uns nos outros \u00e9 uma tarefa dif\u00edcil, e voltaremos a isso em artigos futuros; neste artigo, presumiremos que tal algoritmo de consenso est\u00e1 dispon\u00edvel para n\u00f3s.<\/p>\n

    Quais das propriedades que descrevemos acima est\u00e3o presentes no RANDAO? Ele \u00e9 imprevis\u00edvel, possui a mesma viabilidade que o protocolo de consenso subjacente, mas \u00e9 tendencioso. Em particular, um invasor pode observar a rede e, ap\u00f3s outros participantes revelarem seus n\u00fameros, pode calcular seu XOR e decidir se deve ou n\u00e3o revelar seu n\u00famero para influenciar o resultado. Embora isso n\u00e3o permita que o invasor determine unilateralmente a sa\u00edda do gerador de n\u00fameros aleat\u00f3rios, ainda lhe d\u00e1 1 bit de influ\u00eancia. E se os invasores controlarem v\u00e1rios participantes, o n\u00famero de bits sob seu controle ser\u00e1 igual ao n\u00famero de participantes que eles controlam.<\/p>\n

    \"\u00c9<\/p>\n

    A influ\u00eancia dos invasores pode ser significativamente reduzida se exigir que os participantes revelem os n\u00fameros em ordem. Assim, um invasor s\u00f3 conseguir\u00e1 influenciar o resultado se revelar seu n\u00famero por \u00faltimo. Embora a influ\u00eancia seja muito menor, o algoritmo ainda \u00e9 tendencioso.<\/p>\n

    RANDAO + VDF<\/h3>\n

    Uma das maneiras de tornar o RANDAO n\u00e3o tendencioso \u00e9 a seguinte: depois que todos os n\u00fameros forem revelados e o XOR calculado, seu resultado \u00e9 inserido em uma fun\u00e7\u00e3o que leva muito tempo para ser computada, mas permite verificar a corre\u00e7\u00e3o do c\u00e1lculo muito rapidamente.<\/p>\n

    (vdf_output, vdf_proof) = VDF_compute(input) \/\/ isso \u00e9 muito lento\ncorrect = VDF_verify(input, vdf_output, vdf_proof) \/\/ isso \u00e9 muito r\u00e1pido<\/code><\/pre>\n
    Essa fun\u00e7\u00e3o \u00e9 chamada de Fun\u00e7\u00e3o de Atraso Verific\u00e1vel, ou VDF. Se o c\u00e1lculo do resultado final levar mais tempo do que a fase de revela\u00e7\u00e3o dos n\u00fameros, o atacante n\u00e3o ser\u00e1 capaz de prever o efeito da demonstra\u00e7\u00e3o ou oculta\u00e7\u00e3o de seu n\u00famero, e portanto, perder\u00e1 a capacidade de influenciar o resultado.<\/p>\n
    Desenvolver bons VDF \u00e9 extremamente desafiador. Recentemente, v\u00e1rias inova\u00e7\u00f5es foram feitas, como este<\/u><\/a><\/noindex> e esta,<\/u><\/a><\/noindex> que tornaram os VDF mais aplic\u00e1veis na pr\u00e1tica, e o Ethereum 2.0 planeja a longo prazo usar RANDAO com VDF como fonte de n\u00fameros aleat\u00f3rios. Al\u00e9m do fato de que essa abordagem \u00e9 imprevis\u00edvel e imparcial, ela possui a vantagem adicional de viabilidade, desde que pelo menos dois participantes estejam dispon\u00edveis na rede (desde que o protocolo de consenso utilizado seja vi\u00e1vel com esse pequeno n\u00famero de participantes).<\/p>\n
    A maior dificuldade dessa abordagem reside em configurar o VDF de modo que mesmo um participante com equipamento especializado caro n\u00e3o consiga calcular o VDF antes do t\u00e9rmino da fase de revela\u00e7\u00e3o. Idealmente, o algoritmo deve ter at\u00e9 mesmo uma margem de seguran\u00e7a significativa, digamos, 10x. Abaixo est\u00e1 mostrado um ataque de um participante que possui um ASIC especializado, que lhe permite executar o VDF mais r\u00e1pido do que o tempo alocado para a revela\u00e7\u00e3o da confirma\u00e7\u00e3o RANDAO. Tal participante ainda pode calcular o resultado final usando ou n\u00e3o seu n\u00famero, e depois, com base em seus c\u00e1lculos, decidir se o mostrar\u00e1 ou n\u00e3o.<\/p>\n
    \"\u00c9<\/p>\n
    Para a fam\u00edlia de VDF mencionada acima, o desempenho de um ASIC especializado pode ser mais de 100 vezes superior ao do equipamento comum. Assim, se a fase de revela\u00e7\u00e3o durar 10 segundos, o VDF calculado em um ASIC desse tipo deve levar mais de 100 segundos para ter 10 vezes a margem de seguran\u00e7a, e, portanto, o mesmo VDF calculado em um equipamento comum deve levar 100 x 100 segundos = ~ 3 horas.<\/p>\n
    A Ethereum Foundation planeja resolver esse problema por meio da cria\u00e7\u00e3o de seus pr\u00f3prios ASIC p\u00fablicos e gratuitos. Assim que isso acontecer, todos os outros protocolos tamb\u00e9m poder\u00e3o aproveitar essa tecnologia, mas at\u00e9 l\u00e1, a abordagem RANDAO + VDF n\u00e3o ser\u00e1 t\u00e3o vi\u00e1vel para os protocolos que n\u00e3o podem investir no desenvolvimento de seus pr\u00f3prios ASIC.<\/p>\n
    Muitos artigos, v\u00eddeos e outras informa\u00e7\u00f5es sobre VDF foram reunidos neste site neste site<\/u><\/a><\/noindex>.<\/p>\n
    Usamos c\u00f3digos de apagamento<\/h3>\n
    Nesta se\u00e7\u00e3o, vamos explorar o protocolo de gera\u00e7\u00e3o de n\u00fameros aleat\u00f3rios que utiliza c\u00f3digos de apagamento<\/a><\/noindex>. Ele pode suportar at\u00e9 \u2153 de atacantes, permanecendo vi\u00e1vel, e permite a exist\u00eancia de at\u00e9 \u2154 de atacantes antes que eles possam prever ou influenciar o resultado.<\/p>\n
    A ideia principal do protocolo \u00e9 a seguinte. Para simplificar, vamos supor que existem exatamente 100 participantes. Suponha tamb\u00e9m que todos os participantes t\u00eam localmente uma chave privada e que as chaves p\u00fablicas de todos os participantes s\u00e3o conhecidas por todos os participantes:<\/p>\n
      \n
    1. \n
      Cada participante localmente cria uma longa sequ\u00eancia, a divide em 67 partes, gera c\u00f3digos de apagamento para obter 100 partes, de modo que quaisquer 67 sejam suficientes para reconstruir a sequ\u00eancia, designa cada uma das 100 partes a um dos participantes e as criptografa usando a chave p\u00fablica do mesmo participante. Em seguida, todas as partes codificadas s\u00e3o publicadas.<\/p>\n<\/li>\n
    2. \n
      Os participantes usam algum consenso para alcan\u00e7ar um acordo sobre os conjuntos codificados de 67 participantes espec\u00edficos.<\/p>\n<\/li>\n
    3. \n
      Assim que o consenso \u00e9 alcan\u00e7ado, cada participante pega as partes codificadas em cada um dos 67 conjuntos, criptografadas com sua chave p\u00fablica, decifra todas essas partes e publica todas essas partes decifradas.<\/p>\n<\/li>\n
    4. \n
      Assim que 67 participantes completam a etapa (3), todos os conjuntos acordados podem ser completamente decifrados e restaurados gra\u00e7as \u00e0s propriedades dos c\u00f3digos de apagamento, e o n\u00famero final pode ser obtido como XOR das sequ\u00eancias iniciais a partir das quais os participantes come\u00e7aram na etapa (1).<\/p>\n<\/li>\n<\/ol>\n
      \"\u00c9<\/p>\n
      \u00c9 poss\u00edvel demonstrar que este protocolo \u00e9 imparcial e imprevis\u00edvel. O n\u00famero aleat\u00f3rio resultante \u00e9 definido ap\u00f3s o consenso ser alcan\u00e7ado, mas ningu\u00e9m sabe at\u00e9 que \u2154 dos participantes decodifiquem as partes criptografadas com sua chave p\u00fablica. Assim, o n\u00famero aleat\u00f3rio \u00e9 determinado antes que a informa\u00e7\u00e3o necess\u00e1ria para sua recupera\u00e7\u00e3o seja publicada.<\/p>\n
      O que acontece se, no passo (1), um dos participantes enviar aos outros participantes partes codificadas que n\u00e3o s\u00e3o um c\u00f3digo de apagamento correto de alguma string? Sem modifica\u00e7\u00f5es adicionais, diferentes participantes podem n\u00e3o conseguir recuperar a string de forma alguma, ou recuperar strings diferentes, o que far\u00e1 com que diferentes participantes recebam um n\u00famero aleat\u00f3rio diferente. Para evitar isso, pode-se fazer o seguinte: cada participante, al\u00e9m das partes codificadas, tamb\u00e9m computa a \u00e1rvore de Merkle<\/a><\/noindex> de todas essas partes, e envia a cada participante tanto a parte codificada em si como a raiz da \u00e1rvore de Merkle, e a prova de inclus\u00e3o da parte na \u00e1rvore de Merkle. No consenso do passo (2), os participantes n\u00e3o apenas concordam com um conjunto de conjuntos, mas com um conjunto espec\u00edfico de ra\u00edzes dessas \u00e1rvores (se algum participante se afastou do protocolo e enviou ra\u00edzes diferentes da \u00e1rvore de Merkle para diferentes participantes, e duas dessas ra\u00edzes forem mostradas durante o consenso, sua string n\u00e3o \u00e9 inclu\u00edda no conjunto resultante). No final do consenso, teremos 67 strings codificadas e suas respectivas ra\u00edzes de \u00e1rvore de Merkle, de forma que h\u00e1 pelo menos 67 participantes (n\u00e3o necessariamente os mesmos que propuseram as strings correspondentes), para os quais, para cada uma das 67 strings, h\u00e1 uma mensagem com a parte do c\u00f3digo de apagamento e uma prova da inclus\u00e3o de sua parte na \u00e1rvore de Merkle correspondente.<\/p>\n
      Quando, no passo (4), um participante decodifica 67 partes de uma determinada string e tenta reconstruir a string original, uma das op\u00e7\u00f5es poss\u00edveis \u00e9:<\/p>\n
        \n
      1. \n
        A string \u00e9 restaurada, e se for codificada novamente com c\u00f3digos de apagamento, e a \u00e1rvore de Merkle for calculada para as partes calculadas localmente, a raiz coincide com aquela em que o consenso foi alcan\u00e7ado.<\/p>\n<\/li>\n
      2. \n
        A string \u00e9 restaurada, mas a raiz calculada localmente n\u00e3o corresponde \u00e0quela em que o consenso foi alcan\u00e7ado.<\/p>\n<\/li>\n
      3. \n
        A string n\u00e3o \u00e9 restaurada.<\/p>\n<\/li>\n<\/ol>\n
        \u00c9 f\u00e1cil mostrar que se, para pelo menos um participante, ocorreu a variante (1), ent\u00e3o para todos os participantes ocorrer\u00e1 a variante (1), e vice-versa, se para pelo menos um participante ocorreu a variante (2) ou (3), ent\u00e3o para todos os participantes ocorrer\u00e1 a variante (2) ou (3). Assim, para cada linha no conjunto, ou todos os participantes conseguem restaur\u00e1-la com sucesso, ou todos os participantes n\u00e3o conseguem restaur\u00e1-la. Portanto, o n\u00famero aleat\u00f3rio resultante \u00e9 o XOR apenas das linhas que os participantes conseguiram restaurar.<\/p>\n
        Assinaturas de limite<\/h3>\n
        Outra abordagem para a aleatoriedade envolve o uso das chamadas assinaturas de limite BLS. Um gerador de n\u00fameros aleat\u00f3rios baseado em assinaturas de limite possui exatamente as mesmas garantias que o algoritmo descrito acima baseado em c\u00f3digos de apagamento, mas possui uma assimpt\u00f3tica significativamente menor da quantidade de mensagens transmitidas pela rede para cada n\u00famero gerado.<\/p>\n
        As assinaturas BLS s\u00e3o uma constru\u00e7\u00e3o que permite a v\u00e1rios participantes criar uma \u00fanica assinatura comum para uma mensagem. Essas assinaturas s\u00e3o frequentemente utilizadas para economizar espa\u00e7o e largura de banda, pois n\u00e3o requerem o envio de v\u00e1rias assinaturas. <\/p>\n
        Uma aplica\u00e7\u00e3o frequente para assinaturas BLS em protocolos de blockchain, al\u00e9m da gera\u00e7\u00e3o de n\u00fameros aleat\u00f3rios, \u00e9 a assinatura de blocos em protocolos BFT. Digamos que 100 participantes criam blocos, e um bloco \u00e9 considerado finalizado se 67 deles o assinam. Todos podem apresentar suas partes da assinatura BLS e usar algum algoritmo de consenso para concordar com 67 delas, e ent\u00e3o combin\u00e1-las em uma \u00fanica assinatura BLS. Quaisquer 67 (ou mais) partes podem ser usadas para criar a assinatura final, que depender\u00e1 de quais 67 assinaturas espec\u00edficas foram combinadas e, portanto, pode variar. No entanto, embora a escolha diferente de 67 participantes possa criar uma assinatura diferente, qualquer uma dessas assinaturas ser\u00e1 uma assinatura v\u00e1lida para o bloco. Os outros participantes, ent\u00e3o, precisam apenas receber pela rede e verificar uma \u00fanica assinatura para cada bloco, ao inv\u00e9s de 67, o que reduz significativamente a carga na rede.<\/p>\n
        Descobriu-se que, se as chaves privadas utilizadas pelos participantes forem geradas de uma determinada maneira, ent\u00e3o, independentemente de quais 67 assinaturas (ou mais, mas n\u00e3o menos) sejam agregadas, a assinatura resultante ser\u00e1 a mesma. Isso pode ser usado como uma fonte de aleatoriedade: os participantes primeiro concordam com uma mensagem que assinar\u00e3o (pode ser a sa\u00edda do RANDAO ou simplesmente um hash do \u00faltimo bloco, na verdade, isso n\u00e3o importa, desde que mude a cada vez e seja acordado) e criam uma assinatura BLS para isso. O resultado da gera\u00e7\u00e3o ser\u00e1 imprevis\u00edvel at\u00e9 que 67 participantes forne\u00e7am suas partes, e depois disso, as sa\u00eddas j\u00e1 estar\u00e3o predefinidas e n\u00e3o poder\u00e3o depender das a\u00e7\u00f5es de qualquer participante.<\/p>\n
        Essa abordagem \u00e0 aleatoriedade \u00e9 vi\u00e1vel se pelo menos \u2154 dos participantes estiverem online e seguirem o protocolo, e \u00e9 imparcial e imprevis\u00edvel enquanto pelo menos \u2153 dos participantes seguirem o protocolo. \u00c9 importante notar que um invasor que controla mais de \u2153, mas menos de \u2154 dos participantes pode parar o protocolo, mas n\u00e3o pode prever ou influenciar sua sa\u00edda.<\/p>\n
        As assinaturas de limiar s\u00e3o, por si mesmas, um tema muito interessante. Na segunda parte do artigo, vamos analisar em detalhe como elas funcionam e como os participantes devem gerar suas chaves para que as assinaturas de limiar possam ser usadas como geradores de n\u00fameros aleat\u00f3rios.<\/p>\n
        Para concluir<\/h3>\n
        Este artigo \u00e9 o primeiro de uma s\u00e9rie de artigos t\u00e9cnicos no blog. NEAR<\/a><\/noindex>. NEAR \u00e9 um protocolo de blockchain e plataforma para desenvolvimento de aplicativos descentralizados com foco na simplicidade de desenvolvimento e na facilidade de uso para os usu\u00e1rios finais.<\/p>\n
        O c\u00f3digo do protocolo \u00e9 aberto, nossa implementa\u00e7\u00e3o \u00e9 escrita em Rust e pode ser encontrada aqui<\/a><\/noindex>.<\/p>\n
        Voc\u00ea pode ver como \u00e9 o desenvolvimento para NEAR e experimentar na IDE online aqui<\/a><\/noindex>.<\/p>\n
        Acompanhe todas as not\u00edcias em russo em o grupo no Telegram<\/a><\/noindex> e no grupo no VKontakte<\/a><\/noindex>, e em ingl\u00eas no oficial Twitter<\/a><\/noindex>.<\/p>\n
        At\u00e9 breve!<\/p>\n
        Fonte: 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\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\u00c9 poss\u00edvel gerar n\u00fameros aleat\u00f3rios se n\u00e3o confiamos uns nos outros? Parte 1 | ProHoster","description":"Ol\u00e1, Habr! Neste artigo, vou falar sobre a gera\u00e7\u00e3o de n\u00fameros pseudo-aleat\u00f3rios por participantes que n\u00e3o confiam uns nos outros.","canonical_url":"https:\/\/prohoster.info\/pt\/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":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/95468","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=95468"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/95468\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/95469"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=95468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=95468"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=95468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}