Introdução

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Tal como acontece com o conceito de uma cifra absolutamente forte da criptografia, os verdadeiros protocolos “Publicly Verifiable Random Beacon” (doravante PVRB) apenas tentam chegar o mais próximo possível do esquema ideal, porque em redes reais não é aplicável em sua forma pura: é necessário concordar estritamente em um bit, deve haver muitas rodadas e todas as mensagens devem ser perfeitamente rápidas e sempre entregues. É claro que este não é o caso nas redes reais. Portanto, ao projetar PVRBs para tarefas específicas em blockchains modernos, além da impossibilidade de controlar a aleatoriedade e a força criptográfica resultantes, surgem muitos outros problemas puramente arquitetônicos e técnicos.

Para o PVRB, o próprio blockchain é essencialmente um meio de comunicação em que mensagens = transações. Isso permite abstrair parcialmente problemas de rede, não entrega de mensagens, problemas com middleware - todos esses riscos são assumidos pela rede descentralizada, e seu principal valor para o PVRB é a incapacidade de revogar ou corromper uma transação já enviada - isso faz não permitir que os participantes se recusem a participar do protocolo, a menos que realizem um ataque bem-sucedido ao consenso. Este nível de segurança é aceitável, portanto o PVRB deve ser resistente ao conluio dos participantes exatamente na mesma medida que a cadeia blockchain principal. Além disso, isso sugere que o PVRB deve fazer parte do consenso se a rede concordar com o blockchain principal, mesmo que também concorde com o único resultado aleatório justo. Ou o PVRB é simplesmente um protocolo independente implementado por um contrato inteligente que funciona de forma assíncrona em relação ao blockchain e aos blocos. Ambos os métodos têm suas vantagens e desvantagens, e a escolha entre eles é extremamente nada trivial.

Duas maneiras de implementar PVRB

Descreveremos com mais detalhes duas opções para implementação do PVRB - a versão autônoma, que funciona usando um contrato inteligente independente do blockchain, e a versão integrada por consenso, embutida no protocolo, segundo a qual a rede concorda com o blockchain e o transações a serem incluídas. Em todos os casos, me referirei a mecanismos de blockchain populares: Ethereum, EOS e todos aqueles semelhantes a eles na forma como hospedam e processam contratos inteligentes.

Contrato independente

Nesta versão, o PVRB é um contrato inteligente que aceita transações de produtores aleatórios (doravante denominado RP), processa-as, combina os resultados e, como resultado, chega a um determinado valor que qualquer usuário pode receber deste contrato. Este valor não pode ser armazenado diretamente no contrato, mas sim representado apenas por dados dos quais um e apenas um valor do aleatório resultante pode ser obtido deterministicamente. Neste esquema, os RPs são usuários do blockchain e qualquer pessoa pode participar do processo de geração.

A opção com contrato independente é boa:

• portabilidade (os contratos podem ser arrastados de blockchain para blockchain)
• facilidade de implementação e teste (os contratos são fáceis de escrever e testar)
• comodidade na implementação de esquemas econômicos (é fácil fazer seu próprio token, cuja lógica atende aos propósitos do PVRB)
• possibilidade de lançamento em blockchains já funcionais

Também tem desvantagens:

• fortes limitações em recursos de computação, volume de transações e armazenamento (em outras palavras, cpu/mem/io)
• restrições às operações dentro do contrato (nem todas as instruções estão disponíveis, é difícil conectar bibliotecas externas)
• incapacidade de organizar mensagens mais rapidamente do que as transações incluídas no blockchain

Esta opção é adequada para implementar um PVRB que precisa ser executado em uma rede existente, não contém criptografia complexa e não requer um grande número de interações.

Integrado por consenso

Nesta versão, o PVRB é implementado no código do nó da blockchain, integrado ou executado em paralelo com a troca de mensagens entre os nós da blockchain. Os resultados do protocolo são gravados diretamente nos blocos produzidos e as mensagens do protocolo são enviadas pela rede p2p entre os nós. Como o protocolo resulta em números que devem ser escritos em blocos, a rede deve chegar a um consenso sobre eles. Isso significa que as mensagens PVRB, assim como as transações, devem ser validadas pelos nós e incluídas em blocos para que qualquer participante da rede possa validar a conformidade com o protocolo PVRB. Isso nos leva automaticamente à solução óbvia: se a rede chegar a um consenso sobre um bloco e as transações nele contidas, então o PVRB deverá fazer parte do consenso, e não um protocolo independente. Caso contrário, é possível que um bloco seja válido do ponto de vista de consenso, mas o protocolo PVRB não seja seguido e, do ponto de vista do PVRB, o bloco não possa ser aceito. Assim, se for escolhida a opção “integrada pelo consenso”, o PVRB torna-se uma parte importante do consenso.

Ao descrever as implementações do PVRB no nível de consenso da rede, não se pode de forma alguma evitar questões de finalidade. Finalidade é um mecanismo usado em consensos determinísticos que bloqueia um bloco (e a cadeia que leva a ele) que é final e nunca será descartado, mesmo que ocorra uma bifurcação paralela. Por exemplo, no Bitcoin não existe tal mecanismo - se você publicar uma cadeia de maior complexidade, ela substituirá qualquer outra menos complexa, independentemente do comprimento das cadeias. E na EOS, por exemplo, os finais são os chamados Últimos Blocos Irreversíveis, que aparecem em média a cada 432 blocos (12*21 + 12*15, pré-voto + pré-commit). Este processo está essencialmente à espera de 2/3 das assinaturas dos produtores de blocos (doravante designados por BP). Quando aparecem bifurcações mais antigas que a última LIB, elas são simplesmente descartadas. Este mecanismo permite garantir que a transação seja incluída no blockchain e nunca será revertida, independentemente dos recursos que o invasor possua. Além disso, os blocos finais são blocos assinados por 2/3 BP no Hyperledger, Tendermint e outros consensos baseados em pBFT. Além disso, faz sentido fazer de um protocolo para garantir a finalidade um complemento ao consenso, uma vez que pode funcionar de forma assíncrona com a produção e publicação de blocos. Aqui está uma boa artigo sobre finalidade em Ethereum.

A finalidade é extremamente importante para os usuários, que sem ela podem ser vítimas de um ataque de “gasto duplo”, onde a BP “retém” blocos e os publica depois que a rede “viu” uma boa transação. Se não houver finalidade, então o fork publicado substitui o bloco de uma transação “boa” por outro, de um fork “ruim”, no qual os mesmos fundos são transferidos para o endereço do invasor. No caso do PVRB, os requisitos de finalidade são ainda mais rigorosos, uma vez que construir forks para o PVRB significa a oportunidade para um invasor preparar diversas opções aleatórias para publicar a mais lucrativa, e limitar o tempo de um possível ataque é uma boa solução.

Portanto, a melhor opção é combinar PVRB e finalidade em um protocolo - então o bloco finalizado = aleatório finalizado, e é exatamente isso que precisávamos obter. Agora os jogadores receberão um aleatório garantido em N segundos e podem ter certeza de que é impossível revertê-lo ou reproduzi-lo novamente.

A opção integrada por consenso é boa:

• a possibilidade de implementação assíncrona em relação à produção de blocos - os blocos são produzidos normalmente, mas paralelamente a isso pode funcionar o protocolo PVRB, que não produz aleatoriedade para cada bloco
• a capacidade de implementar criptografia até mesmo pesada, sem as restrições impostas aos contratos inteligentes
• a capacidade de organizar a troca de mensagens mais rapidamente do que as transações incluídas no blockchain, por exemplo, parte do protocolo pode funcionar entre nós sem distribuir mensagens pela rede

Também tem desvantagens:

• Dificuldades em testes e desenvolvimento - você terá que emular erros de rede, nós ausentes, hard forks de rede
• Erros de implementação requerem um hardfork de rede

Ambos os métodos de implementação do PVRB têm direito à vida, mas a implementação de contratos inteligentes em blockchains modernos ainda é bastante limitada em recursos computacionais, e qualquer transição para criptografia séria é muitas vezes simplesmente impossível. E precisaremos de criptografia séria, como será demonstrado a seguir. Embora este problema seja claramente temporário, é necessária criptografia séria nos contratos para resolver muitos problemas, e está aparecendo gradualmente (por exemplo, contratos de sistema para zkSNARKs no Ethereum).

Blockchain, que fornece um canal de mensagens de protocolo transparente e confiável, não faz isso de graça. Qualquer protocolo descentralizado deve levar em conta a possibilidade de um ataque Sybil; qualquer ação pode ser feita pelas forças concertadas de múltiplas contas, portanto, ao projetar, é necessário levar em conta a capacidade dos atacantes de criar um número arbitrário de protocolos. participantes agindo em conluio.

PVRB e variáveis ​​de bloco.

Não menti quando disse que ninguém ainda implementou um bom PVRB, testado por muitos aplicativos de jogos de azar, em blockchains. De onde vêm tantos aplicativos de jogos de azar no Ethereum e no EOS? Isso me surpreende tanto quanto surpreende você, de onde eles conseguiram tantos aleatórios “persistentes” em um ambiente completamente determinístico?

A maneira favorita de obter aleatoriedade no blockchain é pegar algum tipo de informação “imprevisível” do bloco e criar uma informação aleatória com base nela - simplesmente fazendo hash de um ou mais valores. Bom artigo sobre os problemas de tais esquemas aqui. Você pode pegar qualquer um dos valores “imprevisíveis” do bloco, por exemplo, o hash do bloco, o número de transações, a complexidade da rede e outros valores desconhecidos antecipadamente. Em seguida, misture-os, um ou mais, e, em teoria, você deverá obter um resultado aleatório real. Você pode até acrescentar ao artigo que seu esquema é “pós-quântico seguro” (uma vez que existem funções hash à prova de quantum :)).

Mas mesmo os hashes seguros pós-quânticos não são suficientes, infelizmente. O segredo está nos requisitos do PVRB, deixe-me lembrá-los do artigo anterior:

1. O resultado deve ter uma distribuição comprovadamente uniforme, ou seja, ser baseado em criptografia comprovadamente forte.
2. Não é possível controlar nenhum dos bits do resultado. Como consequência, o resultado não pode ser previsto antecipadamente.
3. Você não pode sabotar o protocolo de geração não participando do protocolo ou sobrecarregando a rede com mensagens de ataque
4. Todos os itens acima devem ser resistentes ao conluio de um número permitido de participantes desonestos do protocolo (por exemplo, 1/3 dos participantes).

Nesse caso, apenas o requisito 1 é atendido e não o requisito 2. Ao fazer hash de valores imprevisíveis do bloco, obteremos uma distribuição uniforme e bons aleatórios. Mas a BP pelo menos tem a opção de “publicar o bloco ou não”. Assim, a BP pode escolher pelo menos DUAS opções aleatórias: “a sua” e aquela que surgirá se outra pessoa fizer o bloqueio. A BP pode “bisbilhotar” antecipadamente o que acontecerá se publicar um bloco e simplesmente decidir fazê-lo ou não. Assim, ao jogar, por exemplo, “par-ímpar” ou “vermelho/preto” na roleta, ele só poderá publicar um bloqueio se obtiver uma vitória. Isso também torna inviável a estratégia de usar, por exemplo, um hash de bloco “do futuro”. Nesse caso, dizem que “será utilizado o aleatório, que é obtido através do hash dos dados atuais e do hash de um bloco futuro com altura de, por exemplo, N + 42, onde N é a altura atual do bloco. Isto fortalece um pouco o esquema, mas ainda permite que a BP, ainda que no futuro, escolha se deseja manter o bloco ou publicar.

O software BP, neste caso, torna-se mais complicado, mas não muito. Simplesmente, ao validar e incluir uma transação em um bloco, há uma verificação rápida para saber se haverá ganho e, possivelmente, seleção de parâmetros de uma transação para obter uma alta probabilidade de ganho. Ao mesmo tempo, é quase impossível pegar um BP esperto para tais manipulações, cada vez você pode usar novos endereços e ganhar aos poucos sem levantar suspeitas.

Portanto, os métodos que utilizam informações do bloco não são adequados como implementação universal do PVRB. Numa versão limitada, com restrições no tamanho das apostas, restrições no número de jogadores e/ou registo KYC (para evitar que um jogador utilize vários endereços), estes esquemas podem funcionar para jogos pequenos, mas nada mais.

PVRB e confirmação-revelação.

Ok, graças ao hash e pelo menos à relativa imprevisibilidade do hash do bloco e outras variáveis. Se você resolver o problema dos mineradores avançados, deverá conseguir algo mais adequado. Vamos adicionar usuários a este esquema - deixe-os também influenciar a aleatoriedade: qualquer funcionário do suporte técnico lhe dirá que a coisa mais aleatória nos sistemas de TI são as ações dos usuários :)

Um esquema ingênuo, quando os usuários simplesmente enviam números aleatórios e o resultado é calculado como, por exemplo, um hash de sua soma, não é adequado. Neste caso, o último jogador pode, escolhendo o seu aleatório, controlar qual será o resultado. É por isso que o padrão commit-reveal amplamente utilizado é usado. Os participantes primeiro enviam hashes de seus randoms (commits) e depois abrem os próprios randoms (reveals). A fase de “revelação” começa somente após a coleta dos commits necessários, para que os participantes possam enviar exatamente o hash aleatório do qual enviaram anteriormente. Agora vamos juntar tudo isso com os parâmetros de um bloco, e melhor do que um retirado do futuro (a aleatoriedade só pode ser encontrada em um dos blocos futuros), e pronto - a aleatoriedade está pronta! Agora, qualquer jogador influencia a aleatoriedade resultante e pode “derrotar” o BP malicioso, substituindo-o por sua própria aleatoriedade, desconhecida antecipadamente... Você também pode adicionar proteção contra sabotagem do protocolo, não abrindo-o no estágio de revelação - simplesmente exigindo que uma determinada quantia seja vinculada à transação no momento da confirmação - um depósito de segurança, que será devolvido somente durante o procedimento de revelação. Nesse caso, comprometer-se e não revelar não será lucrativo.

Foi uma boa tentativa, e tais esquemas também existem em DApps de jogos, mas, infelizmente, isso novamente não é suficiente. Agora não só o minerador, mas também qualquer participante do protocolo pode influenciar o resultado. Ainda é possível controlar o valor em si, com menor variabilidade e com custo, mas, como no caso do minerador, se o resultado do sorteio for mais valioso que a taxa de participação no protocolo PVRB, então o aleatório -produtor(RP) pode decidir se revela e ainda pode escolher entre pelo menos duas opções aleatórias.
Mas tornou-se possível punir quem comete e não revela, e este esquema será útil. Sua simplicidade é uma grande vantagem – protocolos mais sérios exigem cálculos muito mais poderosos.

PVRB e assinaturas determinísticas.

Existe outra maneira de forçar o RP a fornecer um número pseudo-aleatório que ele não pode influenciar se for fornecido com uma “pré-imagem” - esta é uma assinatura determinística. Tal assinatura é, por exemplo, RSA e não ECS. Se RP tiver um par de chaves: RSA e ECC, e ele assinar um determinado valor com sua chave privada, então no caso do RSA ele obterá UMA E SÓ UMA assinatura, e no caso do ECS ele poderá gerar qualquer número de diferentes assinaturas válidas. Isso porque ao criar uma assinatura ECS é utilizado um número aleatório, escolhido pelo signatário, podendo ser escolhido de qualquer forma, dando ao signatário a oportunidade de escolher uma entre diversas assinaturas. No caso de RSA: “um valor de entrada” + “um par de chaves” = “uma assinatura”. É impossível prever qual assinatura outro RP obterá, portanto um PVRB com assinaturas determinísticas pode ser organizado combinando as assinaturas RSA de vários participantes que assinaram o mesmo valor. Por exemplo, o aleatório anterior. Este esquema economiza muitos recursos, porque as assinaturas são uma confirmação do comportamento correto de acordo com o protocolo e uma fonte de aleatoriedade.

Contudo, mesmo com assinaturas determinísticas, o esquema ainda é vulnerável ao problema do “último ator”. O último participante ainda pode decidir se publica ou não a assinatura, controlando assim o resultado. Você pode modificar o esquema, adicionar hashes de bloco a ele, fazer rodadas para que o resultado não possa ser previsto com antecedência, mas todas essas técnicas, mesmo levando em conta muitas modificações, ainda deixam sem solução o problema da influência de um participante no coletivo resultam em um ambiente não confiável e só podem funcionar sob restrições econômicas e de tempo. Além disso, o tamanho das chaves RSA (1024 e 2048 bits) é bastante grande e o tamanho das transações blockchain é um parâmetro extremamente importante. Aparentemente não existe uma maneira simples de resolver o problema, vamos em frente.

PVRB e esquemas de compartilhamento secreto

Na criptografia, existem esquemas que podem permitir que a rede concorde com um e apenas um valor de PVRB, embora tais esquemas sejam resistentes a quaisquer ações maliciosas de alguns participantes. Um protocolo útil com o qual vale a pena se familiarizar é o esquema de compartilhamento secreto de Shamir. Serve para dividir um segredo (por exemplo, uma chave secreta) em várias partes e distribuir essas partes para N participantes. O segredo é distribuído de tal forma que M partes de N são suficientes para recuperá-lo, e estas podem ser quaisquer M partes. Se estiver nos dedos, tendo um gráfico de uma função desconhecida, os participantes trocam pontos no gráfico e, após receberem M pontos, toda a função pode ser restaurada.
Uma boa explicação é dada em wiki mas brincar com ele praticamente para reproduzir o protocolo em sua cabeça é útil para demonstração página.

Se o esquema FSSS (Fiat-Shamir Secret Sharing) fosse aplicável na sua forma pura, seria um PVRB indestrutível. Na sua forma mais simples, o protocolo pode ser assim:

• Cada participante gera seu próprio aleatório e distribui ações dele para outros participantes
• Cada participante revela sua parte nos segredos dos outros participantes
• Caso um participante possua mais de M ações, então o número desse participante poderá ser calculado, e será único, independente do conjunto de participantes revelados
• A combinação de aleatórios revelados é o PVRB desejado

Aqui, um participante individual não influencia mais os resultados do protocolo, exceto nos casos em que o alcance do limite de divulgação da aleatoriedade depende exclusivamente dele. Portanto, este protocolo, se houver uma proporção necessária de RPs trabalhando no protocolo e disponíveis, funciona, implementando os requisitos de força criptográfica, e sendo resistente ao problema do “último ator”.

Esta poderia ser uma opção ideal, este esquema PVRB baseado no compartilhamento de segredos Fiat-Shamir é descrito, por exemplo, em este artigo. Mas, como mencionado acima, se você tentar aplicá-lo de frente no blockchain, surgirão limitações técnicas. Aqui está um exemplo de implementação de teste do protocolo no contrato inteligente EOS e sua parte mais importante - a verificação do participante de compartilhamento publicado: código. Você pode ver no código que a validação da prova requer várias multiplicações escalares e os números usados ​​são muito grandes. Deve-se entender que em blockchains a verificação ocorre no momento em que o produtor do bloco processa a transação e, em geral, qualquer participante deve verificar facilmente a exatidão do protocolo, portanto os requisitos para a velocidade da função de verificação são muito sérios . Nesta opção, a opção revelou-se ineficaz, pois a verificação não cabia no limite da transação (0.5 segundos).

A eficiência da verificação é um dos requisitos mais importantes para o uso, em geral, de quaisquer esquemas criptográficos avançados no blockchain. Criar provas, preparar mensagens – esses procedimentos podem ser retirados da cadeia e realizados em computadores de alto desempenho, mas a verificação não pode ser ignorada – esse é outro requisito importante para o PVRB.

PVRB e assinaturas de limite

Conhecendo o esquema de compartilhamento secreto, descobrimos toda uma classe de protocolos unidos pela palavra-chave “limiar”. Quando a divulgação de alguma informação requer a participação de M participantes honestos de N, e o conjunto de participantes honestos pode ser um subconjunto arbitrário de N, falamos de esquemas de “limiares”. São eles que nos permitem lidar com o problema do “último ator”, agora se o atacante não revelar a sua parte do segredo, outro participante honesto fará isso por ele. Esses esquemas permitem acordo sobre um e apenas um significado, mesmo que o protocolo seja sabotado por alguns dos participantes.

A combinação de assinaturas determinísticas e esquemas de limites tornou possível desenvolver um esquema muito conveniente e promissor para a implementação do PVRB - estas são assinaturas de limites determinísticos. Aqui artigo sobre os vários usos de assinaturas de limite, e aqui está outra boa longread de Dash.

O último artigo descreve assinaturas BLS (BLS significa Boneh-Lynn-Shacham, aqui artigo), que possuem uma qualidade muito importante e extremamente conveniente para os programadores - chaves públicas, secretas, públicas e assinaturas BLS podem ser combinadas entre si usando operações matemáticas simples, enquanto suas combinações permanecem chaves e assinaturas válidas, permitindo agregar facilmente muitos assinaturas em uma e muitas chaves públicas em uma. Eles também são determinísticos e produzem o mesmo resultado para os mesmos dados de entrada. Graças a esta qualidade, as combinações de assinaturas BLS são elas próprias chaves válidas, o que permite a implementação de uma opção na qual M de N participantes produzem uma e apenas uma assinatura que é determinística, publicamente verificável e imprevisível até que seja aberta pelo M-ésimo participante.

Em um esquema com assinaturas de limiar BLS, cada participante assina algo usando BLS (por exemplo, o aleatório anterior), e a assinatura de limiar comum é o aleatório desejado. As propriedades criptográficas das assinaturas BLS satisfazem os requisitos de qualidade aleatória, a parte do limite protege contra o “último ator” e a combinabilidade única de chaves torna possível implementar muitos algoritmos mais interessantes que permitem, por exemplo, agregação eficiente de mensagens de protocolo .

Portanto, se você estiver construindo PVRB em seu blockchain, provavelmente acabará com o esquema de assinaturas de limite BLS, vários projetos já o estão usando. Por exemplo, DFinity (aqui benchmark que implementa o circuito, e aqui exemplo de implementação de compartilhamento secreto verificável) ou Keep.network (aqui está seu beacon aleatório papel amareloMas exemplo contrato inteligente servindo o protocolo).

Implementação do PVRB

Infelizmente, ainda não vemos um protocolo pronto implementado em blockchains PVRB que tenha comprovado sua segurança e estabilidade. Embora os protocolos estejam prontos, aplicá-los tecnicamente às soluções existentes não é fácil. Para sistemas centralizados, o PVRB não faz sentido, e os descentralizados são estritamente limitados em todos os recursos computacionais: CPU, memória, armazenamento, E/S. Projetar um PVRB é uma combinação de diferentes protocolos para criar algo que atenda a todos os requisitos de pelo menos algum blockchain viável. Um protocolo calcula com mais eficiência, mas requer mais mensagens entre RPs, enquanto o outro requer muito poucas mensagens, mas criar uma prova pode ser uma tarefa que leva dezenas de minutos, ou até horas.

Vou listar os fatores que você deverá considerar ao escolher um PVRB de qualidade:

• Força criptográfica. Seu PVRB deve ser estritamente imparcial, sem capacidade de controlar um único bit. Em alguns esquemas este não é o caso, então chame um criptógrafo
• O problema do “último ator”. Seu PVRB deve ser resistente a ataques em que um invasor que controla um ou mais RPs possa escolher um de dois resultados.
• Problema de sabotagem de protocolo. Seu PVRB deve ser resistente a ataques onde um invasor controlando um ou mais RPs decide se será aleatório ou não e pode ser garantido ou com uma determinada probabilidade de influenciar isso
• Problema no número de mensagens. Seus RPs devem enviar um mínimo de mensagens para o blockchain e evitar ao máximo ações síncronas, como situações como “enviei algumas informações, estou aguardando uma resposta de um participante específico”. Em redes p2p, principalmente as dispersas geograficamente, não se deve contar com uma resposta rápida
• O problema da complexidade computacional. A verificação de qualquer etapa do PVRB on-chain deve ser extremamente fácil, pois é realizada por todos os clientes plenos da rede. Se a implementação for feita por meio de um contrato inteligente, os requisitos de velocidade serão muito rígidos
• O problema da acessibilidade e da vivacidade. Seu PVRB deve se esforçar para ser resiliente a situações em que parte da rede fica indisponível por um período de tempo e parte do RP simplesmente para de funcionar
• O problema da configuração confiável e da distribuição inicial de chaves. Se o seu PVRB usa a configuração primária do protocolo, então esta é uma história grande e séria à parte. Aqui exemplo. Se os participantes tiverem que informar uns aos outros suas chaves antes de iniciar o protocolo, isso também será um problema se a composição dos participantes mudar
• Problemas de desenvolvimento. Disponibilidade de bibliotecas nos idiomas necessários, sua segurança e desempenho, publicidade, testes complexos, etc.

Por exemplo, as assinaturas BLS de limite têm um problema significativo - antes de começar a trabalhar, os participantes devem distribuir chaves entre si, organizando um grupo dentro do qual o limite funcionará. Isto significa que pelo menos uma ronda de troca numa rede descentralizada terá que esperar, e dado que o rand gerado, por exemplo, é necessário em jogos, quase em tempo real, isto significa que a sabotagem do protocolo é possível nesta fase e as vantagens do esquema de limiares são perdidas. Este problema já é mais simples que os anteriores, mas ainda requer o desenvolvimento de um procedimento separado para a formação de grupos limiares, que deverão ser protegidos economicamente, através de depósitos e saques de fundos (slashing) de participantes que não seguem o protocolo. Além disso, a verificação BLS com um nível aceitável de segurança simplesmente não se encaixa, por exemplo, em uma transação EOS ou Ethereum padrão - simplesmente não há tempo suficiente para verificação. O código do contrato é WebAssembly ou EVM, executado por uma máquina virtual. As funções criptográficas (ainda) não são implementadas nativamente e funcionam dezenas de vezes mais lentamente do que as bibliotecas criptográficas convencionais. Muitos protocolos não atendem aos requisitos simplesmente com base no volume de chaves, por exemplo, 1024 e 2048 bits para RSA, 4 a 8 vezes maior que a assinatura de transação padrão em Bitcoin e Ethereum.

A presença de implementações em diferentes linguagens de programação também desempenha um papel – das quais são poucas, especialmente para novos protocolos. A opção com integração ao consenso requer escrever um protocolo na linguagem da plataforma, então você terá que procurar o código em Go para geth, em Rust para Paridade, em C++ para EOS. Todos terão que procurar o código JavaScript e, como JavaScript e criptografia não são amigos particularmente próximos, o WebAssembly ajudará, que agora definitivamente afirma ser o próximo padrão importante da Internet.

Conclusão

Espero que no anterior статье Consegui convencer vocês de que gerar números aleatórios no blockchain é fundamental para muitos aspectos da vida das redes descentralizadas, e com este artigo mostrei que essa tarefa é extremamente ambiciosa e difícil, mas já existem boas soluções. Em geral, o design final do protocolo só é possível após a realização de testes massivos que levam em consideração todos os aspectos, desde a configuração até a emulação de falhas, portanto, é improvável que você encontre receitas prontas em whitepapers e artigos da equipe, e certamente não encontraremos decida nos próximos um ou dois anos escrever “faça assim, exatamente certo”.

Tchau, pelo nosso PVRB no blockchain em desenvolvimento Haya, decidimos usar assinaturas BLS de limite, planejamos implementar o PVRB em nível de consenso, uma vez que a verificação em contratos inteligentes com um nível de segurança aceitável ainda não é possível. É possível que usemos dois esquemas ao mesmo tempo: primeiro, compartilhamento secreto caro para criar random_seed de longo prazo e, em seguida, use-o como base para geração aleatória de alta frequência usando assinaturas BLS de limite determinístico, talvez nos limitemos a apenas um dos esquemas. Infelizmente, é impossível dizer antecipadamente qual será o protocolo; a única coisa boa é que, como na ciência, nos problemas de engenharia, um resultado negativo também é um resultado, e cada nova tentativa de resolver o problema é mais um passo para a pesquisa de todos os envolvidos no problema. Para atender aos requisitos de negócios, resolvemos um problema prático específico - fornecer às aplicações de jogos uma fonte confiável de entropia, por isso também temos que prestar atenção ao próprio blockchain, em particular às questões de finalidade da cadeia e governança de rede.

E mesmo que ainda não vejamos um PVRB comprovadamente resistente em blockchains, que teria sido usado por tempo suficiente para ser testado por aplicações reais, múltiplas auditorias, cargas e, claro, ataques reais, mas o número de caminhos possíveis confirma que existe uma solução e quais desses algoritmos acabarão por resolver o problema. Teremos o maior prazer em compartilhar os resultados e agradecer a outras equipes que também estão trabalhando neste assunto por artigos e códigos que permitem aos engenheiros não pisar duas vezes no mesmo rake.

Então, quando você encontrar um programador projetando random descentralizado, seja atencioso e atencioso, e forneça ajuda psicológica se necessário :)

Fonte: habr.com