{"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\/pt\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","title":{"rendered":"N\u00fameros aleat\u00f3rios e redes descentralizadas: implementa\u00e7\u00f5es","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1 id=\"vvedenie\">Introdu\u00e7\u00e3o<\/h1>\n<p><\/p>\n<pre><code class=\"plaintext\">function getAbsolutelyRandomNumer() {\n        return 4; \/\/ retorna um n\u00famero absolutamente aleat\u00f3rio!\n}<\/code><\/pre>\n<p><\/p>\n<p>Assim como na ideia de um cifrador absolutamente resistente da criptografia, os protocolos reais de \"Publicly Verifiable Random Beacon\" (PVRB) apenas tentam se aproximar tanto quanto poss\u00edvel do esquema ideal, pois em redes reais sua aplica\u00e7\u00e3o pura \u00e9 invi\u00e1vel: \u00e9 necess\u00e1rio acordar estritamente sobre um \u00fanico bit, deve haver muitos rounds e todas as mensagens devem ser idealmente r\u00e1pidas e sempre entregues. Naturalmente, em redes reais isso n\u00e3o \u00e9 o caso. Portanto, ao projetar PVRB para necessidades espec\u00edficas em blockchains modernas, al\u00e9m da impossibilidade de controlar o aleat\u00f3rio obtido e da resist\u00eancia criptogr\u00e1fica, surgem tamb\u00e9m muitos problemas puramente arquitet\u00f4nicos e t\u00e9cnicos.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>O pr\u00f3prio blockchain serve como um ambiente de comunica\u00e7\u00e3o para PVRB, onde mensagens = transa\u00e7\u00f5es. Isso permite uma abstra\u00e7\u00e3o parcial de problemas de rede, falta de entrega de mensagens, problemas de software intermedi\u00e1rio \u2014 todos esses riscos s\u00e3o assumidos pela rede descentralizada, e seu maior valor para o PVRB \u00e9 a impossibilidade de revogar ou estragar uma transa\u00e7\u00e3o j\u00e1 enviada \u2014 isso n\u00e3o permite que os participantes desistam de participar do protocolo, a menos que tenham realizado um ataque bem-sucedido ao consenso. Esse n\u00edvel de seguran\u00e7a \u00e9 aceit\u00e1vel, portanto o PVRB deve ser resistente a conluios entre os participantes na mesma medida que a cadeia principal do blockchain. Al\u00e9m disso, isso sugere que o PVRB deve ser parte do consenso; se a rede concorda com a cadeia principal de blocos, que ela tamb\u00e9m concorde sobre o \u00fanico aleat\u00f3rio resultante honesto. Ou, o PVRB \u00e9 apenas um protocolo aut\u00f4nomo, implementado por um contrato inteligente, operando de forma ass\u00edncrona em rela\u00e7\u00e3o ao blockchain e aos blocos. Ambos os m\u00e9todos t\u00eam suas vantagens e desvantagens e a escolha entre eles \u00e9 extremamente n\u00e3o trivial. <\/p>\n<p><\/p>\n<h2 id=\"dva-sposoba-implementacii-pvrb\">Duas formas de implementa\u00e7\u00e3o do PVRB<\/h2>\n<p><\/p>\n<p>Descreverei em mais detalhes duas variantes de implementa\u00e7\u00e3o do PVRB \u2014 a vers\u00e3o aut\u00f4noma, funcionando com um contrato inteligente independente do blockchain, e a vers\u00e3o integrada ao consenso \u2014 embutida no protocolo, conforme a qual a rede concorda com a cadeia de blocos e as transa\u00e7\u00f5es inclu\u00eddas. Em todos os casos, terei em mente motores de blockchain populares: Ethereum, EOS, e todos os que s\u00e3o semelhantes a eles em termos de implanta\u00e7\u00e3o e processamento de contratos inteligentes. <\/p>\n<p><\/p>\n<h3 id=\"standalone-contract\">Contrato aut\u00f4nomo<\/h3>\n<p><\/p>\n<p>Nesta variante, o PVRB \u00e9 um contrato inteligente que aceita transa\u00e7\u00f5es de produtores aleat\u00f3rios (daqui em diante RP), processa-as, combina os resultados e, como resultado, chega a um certo valor que qualquer usu\u00e1rio pode obter desse contrato. Esse valor pode n\u00e3o ser armazenado diretamente no contrato, mas ser representado apenas por dados a partir dos quais \u00e9 poss\u00edvel obter de forma determin\u00edstica um \u00fanico valor resultante do aleat\u00f3rio. Neste esquema, RP s\u00e3o os usu\u00e1rios da blockchain, e qualquer um pode participar do processo de gera\u00e7\u00e3o.<\/p>\n<p><\/p>\n<p>A variante com contrato aut\u00f4nomo \u00e9 boa:<\/p>\n<p><\/p>\n<ul>\n<li>portabilidade (os contratos podem ser transferidos de uma blockchain para outra)<\/li>\n<li>simplicidade na implementa\u00e7\u00e3o e teste (os contratos s\u00e3o f\u00e1ceis de escrever e testar)<\/li>\n<li>facilidade na implementa\u00e7\u00e3o de esquemas econ\u00f4micos (\u00e9 f\u00e1cil criar seu token, cuja l\u00f3gica atende aos objetivos do PVRB)<\/li>\n<li>possibilidade de execu\u00e7\u00e3o em blockchains j\u00e1 existentes<\/li>\n<\/ul>\n<p><\/p>\n<p>No entanto, ela tamb\u00e9m apresenta desvantagens:<\/p>\n<p><\/p>\n<ul>\n<li>fortes limita\u00e7\u00f5es de recursos em computa\u00e7\u00f5es, volume de transa\u00e7\u00f5es e armazenamento (simplificando, cpu\/mem\/io)<\/li>\n<li>limita\u00e7\u00f5es nas opera\u00e7\u00f5es dentro do contrato (nem todas as instru\u00e7\u00f5es est\u00e3o dispon\u00edveis, \u00e9 complicado conectar bibliotecas externas)<\/li>\n<li>impossibilidade de organizar a troca de mensagens mais rapidamente do que as transa\u00e7\u00f5es s\u00e3o inclu\u00eddas na blockchain<\/li>\n<\/ul>\n<p><\/p>\n<p>Essa variante \u00e9 adequada para a implementa\u00e7\u00e3o do PVRB, que precisa ser iniciado em uma rede existente, sem complexidade criptogr\u00e1fica e sem exigir um grande n\u00famero de intera\u00e7\u00f5es.<\/p>\n<p><\/p>\n<h3 id=\"consensus-integrated\">Integrado ao consenso<\/h3>\n<p><\/p>\n<p>Nesta vers\u00e3o, o PVRB foi implementado no c\u00f3digo do n\u00f3 de blockchain, integrado ou funcionando paralelamente com a troca de mensagens entre os n\u00f3s da blockchain. Os resultados do protocolo s\u00e3o registrados diretamente nos blocos produzidos, e as mensagens do protocolo s\u00e3o enviadas pela rede p2p entre os n\u00f3s. Como o protocolo resulta em n\u00fameros que devem ser registrados nos blocos, a rede deve chegar a um consenso sobre eles. Isso significa que as mensagens do PVRB, assim como as transa\u00e7\u00f5es, devem ser validadas pelos n\u00f3s e inclu\u00eddas nos blocos, para que qualquer participante da rede possa validar a conformidade com o protocolo PVRB. Isso nos leva automaticamente a uma solu\u00e7\u00e3o \u00f3bvia \u2014 se a rede concorda em consenso sobre um bloco e as transa\u00e7\u00f5es nele, o PVRB deve ser parte do consenso, e n\u00e3o um protocolo separado. Caso contr\u00e1rio, pode ocorrer uma situa\u00e7\u00e3o em que um bloco \u00e9 v\u00e1lido do ponto de vista do consenso, mas o protocolo PVRB n\u00e3o \u00e9 respeitado, e do ponto de vista do PVRB o bloco n\u00e3o pode ser aceito. Assim, se a op\u00e7\u00e3o \u201cintegrada ao consenso\u201d for escolhida, o PVRB torna-se uma parte importante do consenso.<\/p>\n<p><\/p>\n<p>Ao descrever implementa\u00e7\u00f5es do PVRB a n\u00edvel de consenso na rede, de forma alguma se pode evitar quest\u00f5es de finaliza\u00e7\u00e3o. A finaliza\u00e7\u00e3o \u00e9 um mecanismo usado em consensos determin\u00edsticos, que fixa um bloco (e a cadeia que o leva) como final, o qual nunca ser\u00e1 descartado, mesmo que uma bifurca\u00e7\u00e3o paralela apare\u00e7a. Por exemplo, no Bitcoin, esse mecanismo n\u00e3o existe \u2014 se uma cadeia de maior complexidade for publicada, ela substitui qualquer uma menos complexa, independentemente do comprimento das cadeias. J\u00e1 no EOS, os tais chamados Last Irreversible Blocks s\u00e3o considerados finais, que aparecem em m\u00e9dia a cada 432 blocos (12*21 + 12*15, pr\u00e9-vota\u00e7\u00e3o + pr\u00e9-compromisso). Este processo \u00e9, na ess\u00eancia, aguardar 2\/3 das assinaturas dos block-producers (BP). Quando bifurca\u00e7\u00f5es aparecem que s\u00e3o mais antigas que o \u00faltimo LIB, elas simplesmente s\u00e3o descartadas. Este mecanismo permite afirmar com seguran\u00e7a que uma transa\u00e7\u00e3o est\u00e1 inclusa no blockchain e nunca ser\u00e1 revertida, independentemente dos recursos que o atacante possua. Al\u00e9m disso, blocos finais s\u00e3o aqueles assinados por 2\/3 dos BP no Hyperledger, Tendermint e outros consensos baseados em pBFT. Igualmente, o protocolo para garantir a finaliza\u00e7\u00e3o faz sentido ser uma extens\u00e3o sobre o consenso, pois pode funcionar de forma ass\u00edncrona com a produ\u00e7\u00e3o e publica\u00e7\u00e3o de blocos. Aqui est\u00e1 um bom <noindex><a rel=\"nofollow\" href=\"https:\/\/arxiv.org\/pdf\/1710.09437.pdf\">artigo<\/a><\/noindex> sobre a finaliza\u00e7\u00e3o no Ethereum.<\/p>\n<p><\/p>\n<p>A finaliza\u00e7\u00e3o \u00e9 extremamente importante para os usu\u00e1rios, que sem ela podem se tornar v\u00edtimas de ataques de \"double spend\", quando o BP \"mant\u00e9m\" blocos e publica-os ap\u00f3s a rede \"ver\" uma boa transa\u00e7\u00e3o. Se n\u00e3o houver finaliza\u00e7\u00e3o, o fork publicado substitui o bloco com a transa\u00e7\u00e3o \"boa\" por outro de um \"fork ruim\", no qual os mesmos fundos s\u00e3o transferidos para o endere\u00e7o do atacante. No caso do PVRB, os requisitos para a finaliza\u00e7\u00e3o se tornam ainda mais rigorosos, pois a constru\u00e7\u00e3o de forks para o PVRB significa que o atacante pode preparar v\u00e1rias op\u00e7\u00f5es de aleatoriedade com o objetivo de publicar a mais vantajosa para ele, e limitar o tempo poss\u00edvel de ataque \u2014 uma boa solu\u00e7\u00e3o.<\/p>\n<p><\/p>\n<p>Portanto, a melhor op\u00e7\u00e3o \u00e9 combinar PVRB e finaliza\u00e7\u00e3o em um \u00fanico protocolo \u2014 assim, bloco finalizado = aleatoriedade finalizada, e isso \u00e9 exatamente o que era necess\u00e1rio. Agora os jogadores receber\u00e3o uma aleatoriedade garantida em N segundos e podem ter certeza de que revert\u00ea-la ou refaz\u00ea-la \u00e9 imposs\u00edvel.<\/p>\n<p><\/p>\n<p>A op\u00e7\u00e3o com consensus-integrated \u00e9 boa:<\/p>\n<p><\/p>\n<ul>\n<li>a possibilidade de implementa\u00e7\u00e3o ass\u00edncrona em rela\u00e7\u00e3o \u00e0 produ\u00e7\u00e3o de blocos \u2014 os blocos s\u00e3o produzidos como de costume, mas paralelamente a isso, pode funcionar o protocolo PVRB, que produz aleatoriedades n\u00e3o a cada bloco<\/li>\n<li>a possibilidade de implementar criptografia pesada, sem as limita\u00e7\u00f5es impostas a contratos inteligentes<\/li>\n<li>a possibilidade de organizar a troca de mensagens mais r\u00e1pida do que as transa\u00e7\u00f5es s\u00e3o inclu\u00eddas na blockchain, por exemplo, parte do protocolo pode funcionar entre nodos sem a dissemina\u00e7\u00e3o de mensagens pela rede<\/li>\n<\/ul>\n<p><\/p>\n<p>No entanto, ela tamb\u00e9m apresenta desvantagens:<\/p>\n<p><\/p>\n<ul>\n<li>dificuldades no teste e desenvolvimento \u2014 ser\u00e1 necess\u00e1rio emular erros de rede, n\u00f3s que falham, hard forks da rede<\/li>\n<li>erros na implementa\u00e7\u00e3o requerem hard fork da rede<\/li>\n<\/ul>\n<p><\/p>\n<p>Ambas as maneiras de implementar o PVRB t\u00eam direito \u00e0 vida, mas a implementa\u00e7\u00e3o em contratos inteligentes nas blockchains modernas ainda \u00e9 bastante limitada em recursos computacionais, e qualquer transi\u00e7\u00e3o para criptografia s\u00e9ria muitas vezes \u00e9 simplesmente imposs\u00edvel. E a criptografia s\u00e9ria ser\u00e1 necess\u00e1ria, como ser\u00e1 demonstrado a seguir. Embora esse problema tenha um car\u00e1ter claramente tempor\u00e1rio, a criptografia s\u00e9ria nos contratos \u00e9 necess\u00e1ria para resolver muitas tarefas, e gradualmente ela est\u00e1 surgindo (por exemplo, contratos sist\u00eamicos para zkSNARKs no Ethereum).<\/p>\n<p><\/p>\n<p>A blockchain that provides a transparent and reliable communication channel for the protocol does not do it for free. Any decentralized protocol must take into account the possibility of Sybil attacks, as any action can be made by colluding forces of multiple accounts. Therefore, it is essential to consider the attackers' capabilities to create an arbitrary number of protocol participants acting in collusion during the design phase. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-peremennye-bloka\">PVRB and block variables.<\/h2>\n<p><\/p>\n<p>I wasn't lying when I said that a good PVRB, validated by numerous gambling applications, has not yet been implemented in blockchains. Where did so many gambling applications in Ethereum and EOS come from? This surprises me just as much as it does you; where did they find so many 'resilient' random values in a completely deterministic environment?<\/p>\n<p><\/p>\n<p>The favorite way to obtain randomness in the blockchain is to take some 'unpredictable' information from a block and create randomness based on it\u2014simply by hashing one or several values. A good article discussing the problems of such schemes. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.positive.com\/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620\">aqui<\/a><\/noindex>. You can take any of the 'unpredictable' values in the block, such as the block hash, the number of transactions, network difficulty, and other unknown values in advance. Then, hash them, one or more, and ideally, you should get real randomness. You can even add in the whitepaper that your scheme is 'post-quantum secure' (since there are quantum-proof hashing functions :)).<\/p>\n<p><\/p>\n<p>But even post-quantum secure hashes are not enough, unfortunately. The secret lies in the requirements for PVRB, which I remind you of from the previous article:<\/p>\n<p><\/p>\n<ol>\n<li>The result must have a provably uniform distribution, i.e., it should be based on provably secure cryptography.<\/li>\n<li>It is impossible to control any of the bits of the result. Consequently, the result cannot be predicted in advance.<\/li>\n<li>It is not possible to sabotage the generation protocol through non-participation in the protocol or by overloading the network with attacking messages.<\/li>\n<li>All of the above must be resilient to collusion involving an acceptable number of dishonest participants in the protocol (for example, 1\/3 of the participants).<\/li>\n<\/ol>\n<p><\/p>\n<p>Neste caso, apenas o requisito 1 \u00e9 atendido, e o 2 n\u00e3o \u00e9. Ao hashizar valores imprevis\u00edveis do bloco, obteremos uma distribui\u00e7\u00e3o uniforme e boas aleatoriedades. Mas o BP tem pelo menos a op\u00e7\u00e3o de \"publicar o bloco ou n\u00e3o\". Assim, o BP pode, no m\u00ednimo, escolher entre DUAS op\u00e7\u00f5es de aleatoriedade: a sua e a que resultar\u00e1 se o bloco for produzido por outra pessoa. O BP pode \"dar uma espiada\" antecipadamente no que acontecer\u00e1 se publicar o bloco e simplesmente tomar a decis\u00e3o de faz\u00ea-lo ou n\u00e3o. Assim, ao jogar, por exemplo, \"par-\u00edmpar\" ou \"vermelho\/preto\" na roleta, ele pode publicar o bloco apenas se v\u00ea uma vit\u00f3ria. Isso tamb\u00e9m torna in\u00fatil a estrat\u00e9gia de usar, por exemplo, o hash do bloco \"do futuro\". Nesse caso, se diz que \"ser\u00e1 utilizado um aleat\u00f3rio, que resulta do hash das informa\u00e7\u00f5es atuais e do hash de um bloco futuro de altura, por exemplo, N + 42, onde N \u00e9 a altura atual do bloco. Isso fortalece um pouco o esquema, mas ainda assim permite que o BP, mesmo no futuro, escolha segurar o bloco ou public\u00e1-lo.<\/p>\n<p><\/p>\n<p>O software do BP, neste caso, se complica, mas n\u00e3o muito. Durante a valida\u00e7\u00e3o e inclus\u00e3o da transa\u00e7\u00e3o no bloco, h\u00e1 uma r\u00e1pida verifica\u00e7\u00e3o para saber se haver\u00e1 uma vit\u00f3ria e, possivelmente, a escolha de um dos par\u00e2metros da transa\u00e7\u00e3o para obter uma alta probabilidade de vit\u00f3ria. Ao mesmo tempo, capturar um BP inteligente, por tr\u00e1s de tais manipula\u00e7\u00f5es, \u00e9 praticamente imposs\u00edvel, pois a cada vez podem ser usados novos endere\u00e7os e ganhar um pouco, sem levantar suspeitas.<\/p>\n<p><\/p>\n<p>Portanto, m\u00e9todos que utilizam informa\u00e7\u00f5es do bloco n\u00e3o s\u00e3o adequados como uma implementa\u00e7\u00e3o universal do PVRB. Em uma variante restrita, com limita\u00e7\u00f5es nos tamanhos das apostas, limita\u00e7\u00f5es no n\u00famero de jogadores e\/ou registro KYC (para evitar que um jogador use v\u00e1rios endere\u00e7os), esses esquemas podem funcionar para pequenos jogos, mas nada mais.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-commit-reveal\">PVRB e commit-reveal.<\/h2>\n<p><\/p>\n<p>Bem, gra\u00e7as ao hash e \u00e0 relativa imprevisibilidade do hash do bloco e de outras vari\u00e1veis. Se resolvermos o problema do front-running dos mineradores, deve resultar em algo mais s\u00f3lido. Vamos adicionar usu\u00e1rios a este esquema \u2014 que tamb\u00e9m podem influenciar a aleatoriedade: qualquer funcion\u00e1rio de suporte t\u00e9cnico dir\u00e1 que a coisa mais aleat\u00f3ria nos sistemas de TI s\u00e3o as a\u00e7\u00f5es dos usu\u00e1rios \ud83d\ude42<\/p>\n<p><\/p>\n<p>Um esquema ing\u00eanuo, onde os usu\u00e1rios simplesmente enviam n\u00fameros aleat\u00f3rios e o resultado \u00e9 calculado como, por exemplo, o hash de suas somas, n\u00e3o \u00e9 aceit\u00e1vel. Neste caso, o \u00faltimo jogador pode controlar o resultado escolhendo seu pr\u00f3prio aleat\u00f3rio. Portanto, utiliza-se um padr\u00e3o muito amplamente adotado, o commit-reveal. Os participantes primeiro enviam hashes de seus aleat\u00f3rios (commits) e, em seguida, revelam os aleat\u00f3rios (reveals). A fase de \"reveal\" come\u00e7a somente ap\u00f3s a coleta dos necess\u00e1rios commits, permitindo que os participantes enviem exatamente o aleat\u00f3rio cujo hash foi enviado anteriormente. Agora, vamos juntar tudo isso com os par\u00e2metros do bloco, de prefer\u00eancia aqueles do futuro (o aleat\u00f3rio s\u00f3 poder\u00e1 ser conhecido em um dos futuros blocos), e voil\u00e0 \u2014 o aleat\u00f3rio est\u00e1 pronto! Agora, qualquer jogador influencia o aleat\u00f3rio resultante e pode \"vencer\" o malicioso BP, sobrepondo seu aleat\u00f3rio com um aleat\u00f3rio desconhecido previamente... Tamb\u00e9m \u00e9 poss\u00edvel adicionar prote\u00e7\u00e3o contra sabotagem do protocolo durante a fase de reveal \u2014 simplesmente exigindo que, ao fazer um commit, um certo valor seja anexado \u00e0 transa\u00e7\u00e3o \u2014 um dep\u00f3sito de seguran\u00e7a, que ser\u00e1 devolvido apenas durante o processo de reveal. Nesse caso, fazer um commit e n\u00e3o fazer um reveal n\u00e3o ser\u00e1 vantajoso.<\/p>\n<p><\/p>\n<p>Foi uma boa tentativa, e tais esquemas tamb\u00e9m existem em DApps de jogos, mas infelizmente isso n\u00e3o \u00e9 suficiente novamente. Agora, o resultado pode ser influenciado n\u00e3o apenas pelo minerador, mas por qualquer participante do protocolo. O controle sobre o pr\u00f3prio valor ainda \u00e9 poss\u00edvel, com menor variabilidade e por um custo, mas, assim como no caso do minerador, se os resultados do sorteio forem mais valiosos do que a taxa de participa\u00e7\u00e3o no protocolo PVRB, o random-producer (RP) pode decidir se deve fazer o reveal e ainda pode escolher entre pelo menos duas op\u00e7\u00f5es de aleat\u00f3rio.<br \/>\nPor outro lado, surgiu a oportunidade de punir aqueles que fazem commit e n\u00e3o fazem reveal, e este esquema ainda ser\u00e1 \u00fatil. Sua simplicidade \u00e9 uma vantagem significativa \u2014 protocolos mais s\u00e9rios exigem c\u00e1lculos muito mais poderosos.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-determinirovannye-podpisi\">PVRB e assinaturas determin\u00edsticas.<\/h2>\n<p><\/p>\n<p>H\u00e1 outra maneira de for\u00e7ar o RP a fornecer um n\u00famero pseudoaleat\u00f3rio que ele n\u00e3o possa influenciar, se lhe for fornecido um \"prototipo\" \u2014 isso \u00e9 uma assinatura determin\u00edstica. Um exemplo de tal assinatura \u00e9 a RSA, enquanto a ECS n\u00e3o \u00e9. Se o RP possui um par de chaves: RSA e ECC, e assina um determinado valor com sua chave privada, no caso da RSA ele ter\u00e1 UMA E SOMENTE UMA assinatura, enquanto com a ECS ele pode gerar um n\u00famero qualquer de assinaturas v\u00e1lidas diferentes. Isso acontece porque, ao criar uma assinatura ECS, utiliza-se um n\u00famero aleat\u00f3rio escolhido pelo assinante, que pode ser escolhido de qualquer maneira, permitindo ao assinante escolher uma de v\u00e1rias assinaturas. No caso da RSA: \"um valor de entrada\" + \"um par de chaves\" = \"uma assinatura\". N\u00e3o ser\u00e1 poss\u00edvel prever qual ser\u00e1 a assinatura de outro RP, portanto, o PVRB com assinaturas determin\u00edsticas pode ser organizado atrav\u00e9s da combina\u00e7\u00e3o de assinaturas RSA de v\u00e1rios participantes que assinaram o mesmo valor. Por exemplo \u2014 o aleat\u00f3rio anterior. Nesse esquema, muitos recursos s\u00e3o economizados, pois as assinaturas s\u00e3o ao mesmo tempo uma confirma\u00e7\u00e3o da corre\u00e7\u00e3o do comportamento no protocolo e uma fonte de aleatoriedade.<\/p>\n<p><\/p>\n<p>No entanto, mesmo com assinaturas determin\u00edsticas, o esquema ainda \u00e9 vulner\u00e1vel ao problema do \"\u00faltimo ator\". O \u00faltimo participante ainda pode decidir se publica sua assinatura ou n\u00e3o, controlando assim o resultado. \u00c9 poss\u00edvel aprimorar o esquema, adicionando hashes de blocos, realizando rodadas, para que o resultado n\u00e3o possa ser previsto antecipadamente, mas todas essas t\u00e9cnicas, mesmo com v\u00e1rias melhorias, ainda deixam a quest\u00e3o da influ\u00eancia de um participante sobre o resultado coletivo em um ambiente n\u00e3o confi\u00e1vel sem solu\u00e7\u00e3o e podem funcionar apenas sob restri\u00e7\u00f5es econ\u00f4micas e de tempo. Al\u00e9m disso, o tamanho das chaves RSA (1024 e 2048 bits) \u00e9 bastante grande, e o tamanho para transa\u00e7\u00f5es de blockchain \u00e9 um par\u00e2metro extremamente importante. Aparentemente, n\u00e3o conseguiremos resolver o problema de maneira simples, vamos em frente.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-secret-sharing-shemy\">PVRB e esquemas de compartilhamento secreto<\/h2>\n<p><\/p>\n<p>Na criptografia, existem esquemas que permitem que uma rede concorde em um \u00fanico valor PVRB, sendo esses esquemas resistentes a quaisquer a\u00e7\u00f5es maliciosas de parte dos participantes. Um dos protocolos \u00fateis a conhecer \u00e9 o esquema de compartilhamento de segredos de Shamir. Ele serve para dividir um segredo (como uma chave secreta) em v\u00e1rias partes e distribu\u00ed-las a N participantes. O segredo \u00e9 distribu\u00eddo de tal forma que, para sua recupera\u00e7\u00e3o, s\u00e3o necess\u00e1rias M partes de N, e essas podem ser quaisquer M partes. Em termos simples, dado um gr\u00e1fico de uma fun\u00e7\u00e3o desconhecida, os participantes trocam pontos no gr\u00e1fico, e ap\u00f3s receber M pontos, a fun\u00e7\u00e3o completa pode ser restaurada.<br \/>\nUma boa explica\u00e7\u00e3o \u00e9 dada na <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Shamir%27s_Secret_Sharing\">wiki<\/a><\/noindex> e para experimentar na pr\u00e1tica, \u00e9 \u00fatil reproduzir o protocolo na <noindex><a rel=\"nofollow\" href=\"http:\/\/point-at-infinity.org\/ssss\/demo.html\">p\u00e1gina de demonstra\u00e7\u00e3o.<\/a><\/noindex> Se o esquema FSSS (Fiat-Shamir Secret Sharing) fosse aplic\u00e1vel em sua forma pura \u2014 seria um PVRB \u00e0 prova de falhas. No caso mais simples, o protocolo pode ser assim:<\/p>\n<p><\/p>\n<p>Cada participante gera seu pr\u00f3prio random e distribui shares dele aos demais participantes.<\/p>\n<p><\/p>\n<ul>\n<li>Cada participante revela sua parte dos segredos dos outros participantes.<\/li>\n<li>Se um participante acumular mais de M shares, seu n\u00famero pode ser calculado, e ele ser\u00e1 \u00fanico, independentemente do conjunto de participantes que foram revelados.<\/li>\n<li>A combina\u00e7\u00e3o dos randoms revelados \u00e9 o PVRB procurado.<\/li>\n<li>Neste ponto, um participante individual j\u00e1 n\u00e3o influencia os resultados do protocolo, exceto nos casos em que a supera\u00e7\u00e3o do threshold de revela\u00e7\u00e3o do random depende exclusivamente dele. Portanto, este protocolo, na presen\u00e7a da fra\u00e7\u00e3o necess\u00e1ria de participantes operando de acordo com o protocolo e dos RPs dispon\u00edveis, funciona, atendendo aos requisitos de seguran\u00e7a criptogr\u00e1fica e sendo resistente ao problema do \u201c\u00faltimo ator\u201d.<\/li>\n<\/ul>\n<p><\/p>\n<p>Este poderia ser o cen\u00e1rio ideal, esse esquema de PVRB com base no compartilhamento de segredos de Fiat-Shamir \u00e9 descrito, por exemplo, no<\/p>\n<p><\/p>\n<p>este <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2017\/216.pdf\">artigo. Mas, como mencionado anteriormente, ao tentarmos aplic\u00e1-lo diretamente no blockchain, surgem limita\u00e7\u00f5es t\u00e9cnicas. Aqui est\u00e1 um exemplo de implementa\u00e7\u00e3o de teste do protocolo em um contrato inteligente EOS e sua parte mais importante \u2014 a verifica\u00e7\u00e3o do share publicado pelo participante:<\/a><\/noindex> Mas, como mencionado anteriormente, se tentar aplic\u00e1-lo diretamente na blockchain, surgem limita\u00e7\u00f5es t\u00e9cnicas. Aqui est\u00e1 um exemplo de uma implementa\u00e7\u00e3o de teste do protocolo em um smart contract EOS e sua parte mais importante - a verifica\u00e7\u00e3o da share publicada pelo participante: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/eoscraper\/blob\/master\/Proof.hh#L23\">c\u00f3digo<\/a><\/noindex>O c\u00f3digo indica que a valida\u00e7\u00e3o da prova requer v\u00e1rias multiplica\u00e7\u00f5es escalares, e os n\u00fameros utilizados s\u00e3o muito grandes. \u00c9 importante entender que, em blockchains, a verifica\u00e7\u00e3o ocorre no momento em que o produtor de bloco processa a transa\u00e7\u00e3o, e qualquer participante deve ser capaz de verificar facilmente a corre\u00e7\u00e3o do protocolo. Portanto, as exig\u00eancias quanto \u00e0 velocidade da fun\u00e7\u00e3o de verifica\u00e7\u00e3o s\u00e3o muito s\u00e9rias. Neste caso, a solu\u00e7\u00e3o se revelou invi\u00e1vel, j\u00e1 que a verifica\u00e7\u00e3o n\u00e3o se encaixava no limite da transa\u00e7\u00e3o (0,5 s).<\/p>\n<p><\/p>\n<p>A efici\u00eancia da verifica\u00e7\u00e3o \u00e9 uma das exig\u00eancias mais importantes para o uso de qualquer esquema criptogr\u00e1fico avan\u00e7ado em blockchain. A cria\u00e7\u00e3o de provas e a prepara\u00e7\u00e3o de mensagens podem ser realizadas off-chain em computadores de alto desempenho, mas a verifica\u00e7\u00e3o n\u00e3o pode ser contornada \u2014 esse \u00e9 mais um requisito crucial para o PVRB. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-threshold-signatures\">PVRB e assinaturas por limiares<\/h2>\n<p><\/p>\n<p>Ao nos familiarizarmos com o esquema de compartilhamento de segredos, descobrimos uma classe inteira de protocolos que s\u00e3o agrupados sob a palavra-chave \"threshold\". Quando a revela\u00e7\u00e3o de certas informa\u00e7\u00f5es requer a participa\u00e7\u00e3o de M participantes honestos de um total de N, e o conjunto de participantes honestos pode ser qualquer subconjunto de N, falamos de esquemas \"threshold\". Eles permitem lidar com o problema do \"\u00faltimo ator\"; agora, se um invasor n\u00e3o revelar sua parte do segredo, outro participante honesto far\u00e1 isso por ele. Esses esquemas permitem chegar a um \u00fanico e exclusivo valor, mesmo em caso de sabotagem do protocolo por parte de alguns participantes. <\/p>\n<p><\/p>\n<p>A combina\u00e7\u00e3o de assinaturas determin\u00edsticas e esquemas por limiares permitiu desenvolver um esquema muito conveniente e promissor para a implementa\u00e7\u00e3o do PVRB \u2014 s\u00e3o as assinaturas determin\u00edsticas por limiares. Aqui <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2002\/081.pdf\">artigo<\/a><\/noindex> sobre diversas aplica\u00e7\u00f5es de assinaturas por limiares, e aqui est\u00e1 mais um bom <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.dash.org\/secret-sharing-and-threshold-signatures-with-bls-954d1587b5f\">longread<\/a><\/noindex> da Dash. <\/p>\n<p><\/p>\n<p>O \u00faltimo artigo descreve as assinaturas BLS (BLS significa Boneh-Lynn-Shacham, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.iacr.org\/archive\/asiacrypt2001\/22480516.pdf\">aqui<\/a><\/noindex> artigo ), que possuem uma qualidade muito importante e extremamente conveniente para programadores \u2014 chaves p\u00fablicas, chaves secretas e assinaturas BLS podem ser combinadas entre si por meio de opera\u00e7\u00f5es matem\u00e1ticas simples, mantendo-se essas combina\u00e7\u00f5es como chaves e assinaturas v\u00e1lidas, permitindo agregar facilmente muitas assinaturas em uma \u00fanica e muitas chaves p\u00fablicas em uma s\u00f3. Elas tamb\u00e9m possuem determinismo e, com os mesmos dados de entrada, produzem sempre o mesmo resultado. Devido a essa caracter\u00edstica, combina\u00e7\u00f5es de assinaturas BLS s\u00e3o, elas mesmas, chaves v\u00e1lidas, o que permite implementar uma varia\u00e7\u00e3o em que M de N participantes produzem uma \u00fanica assinatura que \u00e9 determinada, publicamente verific\u00e1vel e imprevis\u00edvel at\u00e9 que o M-\u00e9simo participante a revele.<\/p>\n<p><\/p>\n<p>Na esquema de assinaturas BLS com threshold, cada participante assina com BLS algo (por exemplo, um random anterior), e a assinatura de threshold \u00e9 o random desejado. As propriedades criptogr\u00e1ficas das assinaturas BLS atendem aos requisitos de qualidade do random, a parte de threshold protege contra o \"last-actor\", e a combinabilidade \u00fanica das chaves permite implementar muitos algoritmos interessantes que possibilitam, por exemplo, agregar mensagens de protocolo de forma eficiente.<\/p>\n<p><\/p>\n<p>Portanto, se voc\u00ea est\u00e1 construindo PVRB em sua blockchain, \u00e9 muito prov\u00e1vel que voc\u00ea chegue ao esquema de assinaturas BLS com threshold, j\u00e1 utilizado por v\u00e1rios projetos. Por exemplo, DFinity (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/random-beacon\">aqui<\/a><\/noindex> benchmark que implementa o esquema, e <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/vss\/blob\/master\/docs\/index.md\">aqui<\/a><\/noindex> exemplo de implementa\u00e7\u00e3o de verifiable secret sharing), ou Keep.network (aqui est\u00e1 seu random beacon <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-yellowpaper\">yellowpaper<\/a><\/noindex>, e aqui est\u00e1 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-box\">exemplo<\/a><\/noindex> do contrato inteligente que atende ao protocolo).<\/p>\n<p><\/p>\n<h2 id=\"implementaciya-pvrb\">Implementa\u00e7\u00e3o de PVRB<\/h2>\n<p><\/p>\n<p>Infelizmente, ainda n\u00e3o vemos um protocolo implementado nas blockchains PVRB que tenha demonstrado sua seguran\u00e7a e resili\u00eancia. Embora os protocolos em si estejam prontos, sua aplica\u00e7\u00e3o t\u00e9cnica a solu\u00e7\u00f5es existentes \u00e9 complicada. Para sistemas centralizados, o PVRB n\u00e3o faz sentido, enquanto os descentralizados est\u00e3o severamente limitados em todos os recursos computacionais: CPU, mem\u00f3ria, armazenamento, I\/O. O design do PVRB consiste na combina\u00e7\u00e3o de diferentes protocolos para tentar criar algo que atenda a todos os requisitos de pelo menos um blockchain vi\u00e1vel. Um protocolo calcula de forma mais eficiente, mas requer mais mensagens entre RPs, enquanto outro requer muito poucas mensagens, mas a cria\u00e7\u00e3o de uma prova pode ser uma tarefa que leva dezenas de minutos ou at\u00e9 horas.<\/p>\n<p><\/p>\n<p>Vou listar os fatores que voc\u00ea deve considerar ao escolher um PVRB de qualidade:<\/p>\n<p><\/p>\n<ul>\n<li><em>Resist\u00eancia criptogr\u00e1fica<\/em>. Seu PVRB deve ser estritamente imparcial, sem a possibilidade de controle de um \u00fanico bit. Em alguns esquemas, isso n\u00e3o \u00e9 verdade, ent\u00e3o chame um cript\u00f3grafo.<\/li>\n<li><em>Problema do \"\u00faltimo ator\"<\/em>. Seu PVRB deve ser resistente a ataques em que um atacante, controlando um ou mais RPs, pode escolher uma das duas op\u00e7\u00f5es de resultado.<\/li>\n<li><em>Problema de sabotagem do protocolo<\/em>. Seu PVRB deve ser resistente a ataques em que um atacante, controlando um ou mais RPs, decide se deve ou n\u00e3o haver aleatoriedade e pode garantir, ou com uma probabilidade determinada, influenciar isso.<\/li>\n<li><em>Problema da quantidade de mensagens<\/em>. Seus RPs devem enviar o m\u00ednimo poss\u00edvel de mensagens para a blockchain e evitar a\u00e7\u00f5es s\u00edncronas, como situa\u00e7\u00f5es em que \"enviei uma informa\u00e7\u00e3o e estou esperando uma resposta de um participante espec\u00edfico\". Em redes P2P, especialmente geograficamente dispersas, n\u00e3o se deve contar com uma resposta r\u00e1pida.<\/li>\n<li><em>Problema da complexidade computacional<\/em>. A verifica\u00e7\u00e3o de qualquer etapa do PVRB on-chain deve ser extremamente f\u00e1cil, visto que \u00e9 realizada por todos os clientes completos da rede. Se a implementa\u00e7\u00e3o for feita por meio de um contrato inteligente, as exig\u00eancias de velocidade s\u00e3o muito rigorosas.<\/li>\n<li><em>Problema de disponibilidade e continuidade<\/em>. Seu PVRB deve buscar ser resistente a situa\u00e7\u00f5es em que parte da rede se torna indispon\u00edvel por algum tempo e parte dos RPs simplesmente para de funcionar.<\/li>\n<li><em>Problema de configura\u00e7\u00e3o confi\u00e1vel e distribui\u00e7\u00e3o inicial de chaves.<\/em>. Se o seu PVRB utiliza um protocolo de configura\u00e7\u00e3o prim\u00e1rio, essa \u00e9 uma hist\u00f3ria separada, grande e s\u00e9ria. Aqui est\u00e1 <noindex><a rel=\"nofollow\" href=\"https:\/\/z.cash\/ru\/blog\/the-design-of-the-ceremony\/\">exemplo<\/a><\/noindex>. Se os participantes precisam se informar sobre suas chaves antes de iniciar o protocolo, isso tamb\u00e9m \u00e9 um problema, especialmente se a composi\u00e7\u00e3o dos participantes mudar<\/li>\n<li><em>Problemas de desenvolvimento<\/em>. A disponibilidade de bibliotecas nas linguagens necess\u00e1rias, sua seguran\u00e7a e desempenho, a publicidade, testes complexos, etc.<\/li>\n<\/ul>\n<p><\/p>\n<p>Por exemplo, com assinaturas BLS de threshold, h\u00e1 um problema significativo: antes de come\u00e7ar a trabalhar, os participantes precisam trocar chaves entre si, organizando um grupo no qual o threshold funcionar\u00e1. Isso significa que ser\u00e1 necess\u00e1rio aguardar pelo menos uma rodada de troca em uma rede descentralizada, e considerando que a aleatoriedade gerada, por exemplo, \u00e9 necess\u00e1ria em jogos em tempo real, isso significa que o sabotagem do protocolo \u00e9 poss\u00edvel nesta fase e as vantagens do esquema de threshold se perdem. Este problema \u00e9 mais simples do que os anteriores, mas ainda requer o desenvolvimento de um procedimento separado para a forma\u00e7\u00e3o de grupos de threshold, que precisar\u00e1 ser protegido economicamente, atrav\u00e9s de dep\u00f3sitos e penalidades (slashing) para os participantes que n\u00e3o seguirem o protocolo. Al\u00e9m disso, a verifica\u00e7\u00e3o de BLS com um n\u00edvel aceit\u00e1vel de seguran\u00e7a simplesmente n\u00e3o se encaixa, por exemplo, em uma transa\u00e7\u00e3o padr\u00e3o da EOS ou Ethereum \u2014 simplesmente n\u00e3o h\u00e1 tempo suficiente para a verifica\u00e7\u00e3o. O c\u00f3digo dos contratos \u00e9 WebAssembly ou EVM, executado por uma m\u00e1quina virtual. As fun\u00e7\u00f5es criptogr\u00e1ficas n\u00e3o s\u00e3o implementadas nativamente (ainda), e operam dezenas de vezes mais devagar do que bibliotecas criptogr\u00e1ficas normais. Muitos protocolos n\u00e3o atendem aos requisitos simplesmente com base no volume de chaves, por exemplo, s\u00e3o 1024 e 2048 bits para RSA, 4 a 8 vezes mais do que a assinatura padr\u00e3o de uma transa\u00e7\u00e3o no Bitcoin e Ethereum.<\/p>\n<p><\/p>\n<p>A presen\u00e7a de implementa\u00e7\u00f5es em v\u00e1rias linguagens de programa\u00e7\u00e3o tamb\u00e9m desempenha um papel \u2014 existem poucas, especialmente para novos protocolos. A op\u00e7\u00e3o de integra\u00e7\u00e3o no consenso exige que o protocolo seja escrito na linguagem da plataforma, ent\u00e3o ser\u00e1 necess\u00e1rio procurar c\u00f3digo em Go para geth, em Rust para Parity, em C++ para EOS. O c\u00f3digo em JavaScript precisar\u00e1 ser procurado por todos, e como JavaScript e criptografia n\u00e3o s\u00e3o exatamente amigos, o WebAssembly ajudar\u00e1, que agora certamente se afirma como o pr\u00f3ximo importante padr\u00e3o da internet.<\/p>\n<p><\/p>\n<h2 id=\"zaklyuchenie\">Conclus\u00e3o<\/h2>\n<p><\/p>\n<p>Espero que no anterior <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/448330\/\">artigo<\/a><\/noindex> Consegui convenc\u00ea-lo de que a gera\u00e7\u00e3o de n\u00fameros aleat\u00f3rios em blockchain \u00e9 criticamente importante para diversos aspectos da vida em redes descentralizadas, e neste artigo mostrei que essa tarefa \u00e9 extremamente ambiciosa e desafiadora, mas j\u00e1 existem boas solu\u00e7\u00f5es. De fato, o design final do protocolo s\u00f3 ser\u00e1 poss\u00edvel ap\u00f3s a realiza\u00e7\u00e3o de testes extensivos que considerem todos os aspectos, desde a configura\u00e7\u00e3o at\u00e9 a simula\u00e7\u00e3o de falhas, portanto, \u00e9 improv\u00e1vel que voc\u00ea encontre receitas prontas nos whitepapers das equipes ou em artigos, e n\u00f3s, nos pr\u00f3ximos um ou dois anos, definitivamente n\u00e3o nos atreveremos a escrever \u201cfa\u00e7am assim, isso est\u00e1 absolutamente correto\u201d. <\/p>\n<p><\/p>\n<p>At\u00e9 agora, para o nosso PVRB no blockchain em desenvolvimento <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/haya\">Haya<\/a><\/noindex>, decidimos utilizar assinaturas BLS de limiar, planejamos implementar o PVRB no n\u00edvel de consenso, uma vez que a verifica\u00e7\u00e3o em contratos inteligentes com um n\u00edvel aceit\u00e1vel de seguran\u00e7a ainda \u00e9 imposs\u00edvel. \u00c9 poss\u00edvel que utilizemos duas abordagens: primeiro uma cara divis\u00e3o secreta para criar um random_seed de longo prazo, que ser\u00e1 usado como base para a gera\u00e7\u00e3o de aleatoriedade de alta frequ\u00eancia com assinaturas BLS de limiar determin\u00edsticas, ou podemos nos limitar a uma \u00fanica abordagem. Dizer de antem\u00e3o como ser\u00e1 o protocolo, infelizmente, \u00e9 imposs\u00edvel, mas \u00e9 encorajador que, assim como na ci\u00eancia, em tarefas de engenharia, um resultado negativo tamb\u00e9m \u00e9 um resultado, e cada nova tentativa de resolver um problema \u00e9 um passo a mais para a pesquisa de todos os que se ocupam dessa quest\u00e3o. Para atender \u00e0s exig\u00eancias do neg\u00f3cio, estamos resolvendo uma tarefa pr\u00e1tica espec\u00edfica \u2014 fornecer aplicativos de jogos com uma fonte de entropia confi\u00e1vel, portanto, temos que prestar aten\u00e7\u00e3o tamb\u00e9m ao pr\u00f3prio blockchain, especialmente em rela\u00e7\u00e3o \u00e0 finaliza\u00e7\u00e3o da cadeia e \u00e0 governan\u00e7a da rede. <\/p>\n<p><\/p>\n<p>E embora atualmente n\u00e3o vejamos um PVRB comprovadamente resistente em blockchains, que tenha sido usado por tempo suficiente para passar pelos testes de aplicativos reais, m\u00faltiplas auditorias, cargas de trabalho e, claro, ataques reais, o n\u00famero de caminhos poss\u00edveis confirma que a solu\u00e7\u00e3o existe, e algum desses algoritmos, no final, resolver\u00e1 o problema. Teremos prazer em compartilhar os resultados e agradecemos \u00e0s outras equipes que tamb\u00e9m est\u00e3o lidando com essa quest\u00e3o por seus artigos e c\u00f3digos que permitem que engenheiros n\u00e3o cometam os mesmos erros repetidamente. <\/p>\n<p><\/p>\n<p>Portanto, ao encontrar um programador projetando um randomizador descentralizado, seja cauteloso e atencioso, e forne\u00e7a apoio psicol\u00f3gico se necess\u00e1rio \ud83d\ude42<\/p>\n<p>Fonte: <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.3 - 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\/pt\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/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 aleat\u00f3rios e redes descentralizadas: implementa\u00e7\u00f5es | ProHoster","description":"Introdu\u00e7\u00e3o function getAbsolutelyRandomNumer() { return 4; \/\/ retorna um n\u00famero absolutamente aleat\u00f3rio!","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","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\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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/33888","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=33888"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/33888\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=33888"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=33888"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=33888"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}