Introdução

function getAbsolutelyRandomNumer() {
        return 4; // retorna um número absolutamente aleatório!
}

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ível do esquema ideal, pois em redes reais sua aplicação pura é inviável: é necessário acordar estritamente sobre um único bit, deve haver muitos rounds e todas as mensagens devem ser idealmente rápidas e sempre entregues. Naturalmente, em redes reais isso não é o caso. Portanto, ao projetar PVRB para necessidades específicas em blockchains modernas, além da impossibilidade de controlar o aleatório obtido e da resistência criptográfica, surgem também muitos problemas puramente arquitetônicos e técnicos.

O próprio blockchain serve como um ambiente de comunicação para PVRB, onde mensagens = transações. Isso permite uma abstração parcial de problemas de rede, falta de entrega de mensagens, problemas de software intermediário — todos esses riscos são assumidos pela rede descentralizada, e seu maior valor para o PVRB é a impossibilidade de revogar ou estragar uma transação já enviada — isso não permite que os participantes desistam de participar do protocolo, a menos que tenham realizado um ataque bem-sucedido ao consenso. Esse nível de segurança é aceitável, portanto o PVRB deve ser resistente a conluios entre os participantes na mesma medida que a cadeia principal do blockchain. Além disso, isso sugere que o PVRB deve ser parte do consenso; se a rede concorda com a cadeia principal de blocos, que ela também concorde sobre o único aleatório resultante honesto. Ou, o PVRB é apenas um protocolo autônomo, implementado por um contrato inteligente, operando 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 não trivial.

Duas formas de implementação do PVRB

Descreverei em mais detalhes duas variantes de implementação do PVRB — a versão autônoma, funcionando com um contrato inteligente independente do blockchain, e a versão integrada ao consenso — embutida no protocolo, conforme a qual a rede concorda com a cadeia de blocos e as transações incluídas. Em todos os casos, terei em mente motores de blockchain populares: Ethereum, EOS, e todos os que são semelhantes a eles em termos de implantação e processamento de contratos inteligentes.

Contrato autônomo

Nesta variante, o PVRB é um contrato inteligente que aceita transações de produtores aleatórios (daqui em diante RP), processa-as, combina os resultados e, como resultado, chega a um certo valor que qualquer usuário pode obter desse contrato. Esse valor pode não ser armazenado diretamente no contrato, mas ser representado apenas por dados a partir dos quais é possível obter de forma determinística um único valor resultante do aleatório. Neste esquema, RP são os usuários da blockchain, e qualquer um pode participar do processo de geração.

A variante com contrato autônomo é boa:

• portabilidade (os contratos podem ser transferidos de uma blockchain para outra)
• simplicidade na implementação e teste (os contratos são fáceis de escrever e testar)
• facilidade na implementação de esquemas econômicos (é fácil criar seu token, cuja lógica atende aos objetivos do PVRB)
• possibilidade de execução em blockchains já existentes

No entanto, ela também apresenta desvantagens:

• fortes limitações de recursos em computações, volume de transações e armazenamento (simplificando, cpu/mem/io)
• limitações nas operações dentro do contrato (nem todas as instruções estão disponíveis, é complicado conectar bibliotecas externas)
• impossibilidade de organizar a troca de mensagens mais rapidamente do que as transações são incluídas na blockchain

Essa variante é adequada para a implementação do PVRB, que precisa ser iniciado em uma rede existente, sem complexidade criptográfica e sem exigir um grande número de interações.

Integrado ao consenso

Nesta versão, o PVRB foi implementado no código do nó de blockchain, integrado ou funcionando paralelamente com a troca de mensagens entre os nós da blockchain. Os resultados do protocolo são registrados 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 registrados nos blocos, a rede deve chegar a um consenso sobre eles. Isso significa que as mensagens do PVRB, assim como as transações, devem ser validadas pelos nós e incluídas nos blocos, para que qualquer participante da rede possa validar a conformidade com o protocolo PVRB. Isso nos leva automaticamente a uma solução óbvia — se a rede concorda em consenso sobre um bloco e as transações nele, o PVRB deve ser parte do consenso, e não um protocolo separado. Caso contrário, pode ocorrer uma situação em que um bloco é válido do ponto de vista do consenso, mas o protocolo PVRB não é respeitado, e do ponto de vista do PVRB o bloco não pode ser aceito. Assim, se a opção “integrada ao consenso” for escolhida, o PVRB torna-se uma parte importante do consenso.

Ao descrever implementações do PVRB a nível de consenso na rede, de forma alguma se pode evitar questões de finalização. A finalização é um mecanismo usado em consensos determinísticos, que fixa um bloco (e a cadeia que o leva) como final, o qual nunca será descartado, mesmo que uma bifurcação paralela apareça. Por exemplo, no Bitcoin, esse mecanismo não existe — se uma cadeia de maior complexidade for publicada, ela substitui qualquer uma menos complexa, independentemente do comprimento das cadeias. Já no EOS, os tais chamados Last Irreversible Blocks são considerados finais, que aparecem em média a cada 432 blocos (12*21 + 12*15, pré-votação + pré-compromisso). Este processo é, na essência, aguardar 2/3 das assinaturas dos block-producers (BP). Quando bifurcações aparecem que são mais antigas que o último LIB, elas simplesmente são descartadas. Este mecanismo permite afirmar com segurança que uma transação está inclusa no blockchain e nunca será revertida, independentemente dos recursos que o atacante possua. Além disso, blocos finais são aqueles assinados por 2/3 dos BP no Hyperledger, Tendermint e outros consensos baseados em pBFT. Igualmente, o protocolo para garantir a finalização faz sentido ser uma extensão sobre o consenso, pois pode funcionar de forma assíncrona com a produção e publicação de blocos. Aqui está um bom artigo sobre a finalização no Ethereum.

A finalização é extremamente importante para os usuários, que sem ela podem se tornar vítimas de ataques de "double spend", quando o BP "mantém" blocos e publica-os após a rede "ver" uma boa transação. Se não houver finalização, o fork publicado substitui o bloco com a transação "boa" por outro de um "fork ruim", no qual os mesmos fundos são transferidos para o endereço do atacante. No caso do PVRB, os requisitos para a finalização se tornam ainda mais rigorosos, pois a construção de forks para o PVRB significa que o atacante pode preparar várias opções de aleatoriedade com o objetivo de publicar a mais vantajosa para ele, e limitar o tempo possível de ataque — uma boa solução.

Portanto, a melhor opção é combinar PVRB e finalização em um único protocolo — assim, bloco finalizado = aleatoriedade finalizada, e isso é exatamente o que era necessário. Agora os jogadores receberão uma aleatoriedade garantida em N segundos e podem ter certeza de que revertê-la ou refazê-la é impossível.

A opção com consensus-integrated é boa:

• a possibilidade de implementação assíncrona em relação à produção de blocos — os blocos são produzidos como de costume, mas paralelamente a isso, pode funcionar o protocolo PVRB, que produz aleatoriedades não a cada bloco
• a possibilidade de implementar criptografia pesada, sem as limitações impostas a contratos inteligentes
• a possibilidade de organizar a troca de mensagens mais rápida do que as transações são incluídas na blockchain, por exemplo, parte do protocolo pode funcionar entre nodos sem a disseminação de mensagens pela rede

No entanto, ela também apresenta desvantagens:

• dificuldades no teste e desenvolvimento — será necessário emular erros de rede, nós que falham, hard forks da rede
• erros na implementação requerem hard fork da rede

Ambas as maneiras de implementar o PVRB têm direito à vida, mas a implementação em contratos inteligentes nas blockchains modernas ainda é bastante limitada em recursos computacionais, e qualquer transição para criptografia séria muitas vezes é simplesmente impossível. E a criptografia séria será necessária, como será demonstrado a seguir. Embora esse problema tenha um caráter claramente temporário, a criptografia séria nos contratos é necessária para resolver muitas tarefas, e gradualmente ela está surgindo (por exemplo, contratos sistêmicos para zkSNARKs no Ethereum).

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.

PVRB and block variables.

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?

The favorite way to obtain randomness in the blockchain is to take some 'unpredictable' information from a block and create randomness based on it—simply by hashing one or several values. A good article discussing the problems of such schemes. aqui. 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 :)).

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:

1. The result must have a provably uniform distribution, i.e., it should be based on provably secure cryptography.
2. It is impossible to control any of the bits of the result. Consequently, the result cannot be predicted in advance.
3. It is not possible to sabotage the generation protocol through non-participation in the protocol or by overloading the network with attacking messages.
4. 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).

Neste caso, apenas o requisito 1 é atendido, e o 2 não é. Ao hashizar valores imprevisíveis do bloco, obteremos uma distribuição uniforme e boas aleatoriedades. Mas o BP tem pelo menos a opção de "publicar o bloco ou não". Assim, o BP pode, no mínimo, escolher entre DUAS opções de aleatoriedade: a sua e a que resultará se o bloco for produzido por outra pessoa. O BP pode "dar uma espiada" antecipadamente no que acontecerá se publicar o bloco e simplesmente tomar a decisão de fazê-lo ou não. Assim, ao jogar, por exemplo, "par-ímpar" ou "vermelho/preto" na roleta, ele pode publicar o bloco apenas se vê uma vitória. Isso também torna inútil a estratégia de usar, por exemplo, o hash do bloco "do futuro". Nesse caso, se diz que "será utilizado um aleatório, que resulta do hash das informações atuais e do hash de um bloco futuro de altura, por exemplo, N + 42, onde N é 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á-lo.

O software do BP, neste caso, se complica, mas não muito. Durante a validação e inclusão da transação no bloco, há uma rápida verificação para saber se haverá uma vitória e, possivelmente, a escolha de um dos parâmetros da transação para obter uma alta probabilidade de vitória. Ao mesmo tempo, capturar um BP inteligente, por trás de tais manipulações, é praticamente impossível, pois a cada vez podem ser usados novos endereços e ganhar um pouco, sem levantar suspeitas.

Portanto, métodos que utilizam informações do bloco não são adequados como uma implementação universal do PVRB. Em uma variante restrita, com limitações nos tamanhos das apostas, limitações no número de jogadores e/ou registro KYC (para evitar que um jogador use vários endereços), esses esquemas podem funcionar para pequenos jogos, mas nada mais.

PVRB e commit-reveal.

Bem, graças ao hash e à relativa imprevisibilidade do hash do bloco e de outras variáveis. Se resolvermos o problema do front-running dos mineradores, deve resultar em algo mais sólido. Vamos adicionar usuários a este esquema — que também podem influenciar a aleatoriedade: qualquer funcionário de suporte técnico dirá que a coisa mais aleatória nos sistemas de TI são as ações dos usuários 🙂

Um esquema ingênuo, onde os usuários simplesmente enviam números aleatórios e o resultado é calculado como, por exemplo, o hash de suas somas, não é aceitável. Neste caso, o último jogador pode controlar o resultado escolhendo seu próprio aleatório. Portanto, utiliza-se um padrão muito amplamente adotado, o commit-reveal. Os participantes primeiro enviam hashes de seus aleatórios (commits) e, em seguida, revelam os aleatórios (reveals). A fase de "reveal" começa somente após a coleta dos necessários commits, permitindo que os participantes enviem exatamente o aleatório cujo hash foi enviado anteriormente. Agora, vamos juntar tudo isso com os parâmetros do bloco, de preferência aqueles do futuro (o aleatório só poderá ser conhecido em um dos futuros blocos), e voilà — o aleatório está pronto! Agora, qualquer jogador influencia o aleatório resultante e pode "vencer" o malicioso BP, sobrepondo seu aleatório com um aleatório desconhecido previamente... Também é possível adicionar proteção contra sabotagem do protocolo durante a fase de reveal — simplesmente exigindo que, ao fazer um commit, um certo valor seja anexado à transação — um depósito de segurança, que será devolvido apenas durante o processo de reveal. Nesse caso, fazer um commit e não fazer um reveal não será vantajoso.

Foi uma boa tentativa, e tais esquemas também existem em DApps de jogos, mas infelizmente isso não é suficiente novamente. Agora, o resultado pode ser influenciado não apenas pelo minerador, mas por qualquer participante do protocolo. O controle sobre o próprio valor ainda é possível, 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ção no protocolo PVRB, o random-producer (RP) pode decidir se deve fazer o reveal e ainda pode escolher entre pelo menos duas opções de aleatório.
Por outro lado, surgiu a oportunidade de punir aqueles que fazem commit e não fazem reveal, e este esquema ainda será útil. Sua simplicidade é uma vantagem significativa — protocolos mais sérios exigem cálculos muito mais poderosos.

PVRB e assinaturas determinísticas.

Há outra maneira de forçar o RP a fornecer um número pseudoaleatório que ele não possa influenciar, se lhe for fornecido um "prototipo" — isso é uma assinatura determinística. Um exemplo de tal assinatura é a RSA, enquanto a ECS não é. 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á UMA E SOMENTE UMA assinatura, enquanto com a ECS ele pode gerar um número qualquer de assinaturas válidas diferentes. Isso acontece porque, ao criar uma assinatura ECS, utiliza-se um número aleatório escolhido pelo assinante, que pode ser escolhido de qualquer maneira, permitindo ao assinante escolher uma de várias assinaturas. No caso da RSA: "um valor de entrada" + "um par de chaves" = "uma assinatura". Não será possível prever qual será a assinatura de outro RP, portanto, o PVRB com assinaturas determinísticas pode ser organizado através da combinação de assinaturas RSA de vários participantes que assinaram o mesmo valor. Por exemplo — o aleatório anterior. Nesse esquema, muitos recursos são economizados, pois as assinaturas são ao mesmo tempo uma confirmação da correção do comportamento no protocolo e uma fonte de aleatoriedade.

No entanto, mesmo com assinaturas determinísticas, o esquema ainda é vulnerável ao problema do "último ator". O último participante ainda pode decidir se publica sua assinatura ou não, controlando assim o resultado. É possível aprimorar o esquema, adicionando hashes de blocos, realizando rodadas, para que o resultado não possa ser previsto antecipadamente, mas todas essas técnicas, mesmo com várias melhorias, ainda deixam a questão da influência de um participante sobre o resultado coletivo em um ambiente não confiável sem solução e podem funcionar apenas 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 para transações de blockchain é um parâmetro extremamente importante. Aparentemente, não conseguiremos resolver o problema de maneira simples, vamos em frente.

PVRB e esquemas de compartilhamento secreto

Na criptografia, existem esquemas que permitem que uma rede concorde em um único valor PVRB, sendo esses esquemas resistentes a quaisquer ações maliciosas de parte dos participantes. Um dos protocolos úteis a conhecer é o esquema de compartilhamento de segredos de Shamir. Ele serve para dividir um segredo (como uma chave secreta) em várias partes e distribuí-las a N participantes. O segredo é distribuído de tal forma que, para sua recuperação, são necessárias M partes de N, e essas podem ser quaisquer M partes. Em termos simples, dado um gráfico de uma função desconhecida, os participantes trocam pontos no gráfico, e após receber M pontos, a função completa pode ser restaurada.
Uma boa explicação é dada na wiki e para experimentar na prática, é útil reproduzir o protocolo na página de demonstração. Se o esquema FSSS (Fiat-Shamir Secret Sharing) fosse aplicável em sua forma pura — seria um PVRB à prova de falhas. No caso mais simples, o protocolo pode ser assim:

Cada participante gera seu próprio random e distribui shares dele aos demais participantes.

• Cada participante revela sua parte dos segredos dos outros participantes.
• Se um participante acumular mais de M shares, seu número pode ser calculado, e ele será único, independentemente do conjunto de participantes que foram revelados.
• A combinação dos randoms revelados é o PVRB procurado.
• Neste ponto, um participante individual já não influencia os resultados do protocolo, exceto nos casos em que a superação do threshold de revelação do random depende exclusivamente dele. Portanto, este protocolo, na presença da fração necessária de participantes operando de acordo com o protocolo e dos RPs disponíveis, funciona, atendendo aos requisitos de segurança criptográfica e sendo resistente ao problema do “último ator”.

Este poderia ser o cenário ideal, esse esquema de PVRB com base no compartilhamento de segredos de Fiat-Shamir é descrito, por exemplo, no

este artigo. Mas, como mencionado anteriormente, ao tentarmos aplicá-lo diretamente no blockchain, surgem limitações técnicas. Aqui está um exemplo de implementação de teste do protocolo em um contrato inteligente EOS e sua parte mais importante — a verificação do share publicado pelo participante: Mas, como mencionado anteriormente, se tentar aplicá-lo diretamente na blockchain, surgem limitações técnicas. Aqui está um exemplo de uma implementação de teste do protocolo em um smart contract EOS e sua parte mais importante - a verificação da share publicada pelo participante: códigoO código indica que a validação da prova requer várias multiplicações escalares, e os números utilizados são muito grandes. É importante entender que, em blockchains, a verificação ocorre no momento em que o produtor de bloco processa a transação, e qualquer participante deve ser capaz de verificar facilmente a correção do protocolo. Portanto, as exigências quanto à velocidade da função de verificação são muito sérias. Neste caso, a solução se revelou inviável, já que a verificação não se encaixava no limite da transação (0,5 s).

A eficiência da verificação é uma das exigências mais importantes para o uso de qualquer esquema criptográfico avançado em blockchain. A criação de provas e a preparação de mensagens podem ser realizadas off-chain em computadores de alto desempenho, mas a verificação não pode ser contornada — esse é mais um requisito crucial para o PVRB.

PVRB e assinaturas por limiares

Ao nos familiarizarmos com o esquema de compartilhamento de segredos, descobrimos uma classe inteira de protocolos que são agrupados sob a palavra-chave "threshold". Quando a revelação de certas informações requer a participação 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 "último ator"; agora, se um invasor não revelar sua parte do segredo, outro participante honesto fará isso por ele. Esses esquemas permitem chegar a um único e exclusivo valor, mesmo em caso de sabotagem do protocolo por parte de alguns participantes.

A combinação de assinaturas determinísticas e esquemas por limiares permitiu desenvolver um esquema muito conveniente e promissor para a implementação do PVRB — são as assinaturas determinísticas por limiares. Aqui artigo sobre diversas aplicações de assinaturas por limiares, e aqui está mais um bom longread da Dash.

O último artigo descreve as assinaturas BLS (BLS significa Boneh-Lynn-Shacham, aqui artigo ), que possuem uma qualidade muito importante e extremamente conveniente para programadores — chaves públicas, chaves secretas e assinaturas BLS podem ser combinadas entre si por meio de operações matemáticas simples, mantendo-se essas combinações como chaves e assinaturas válidas, permitindo agregar facilmente muitas assinaturas em uma única e muitas chaves públicas em uma só. Elas também possuem determinismo e, com os mesmos dados de entrada, produzem sempre o mesmo resultado. Devido a essa característica, combinações de assinaturas BLS são, elas mesmas, chaves válidas, o que permite implementar uma variação em que M de N participantes produzem uma única assinatura que é determinada, publicamente verificável e imprevisível até que o M-ésimo participante a revele.

Na esquema de assinaturas BLS com threshold, cada participante assina com BLS algo (por exemplo, um random anterior), e a assinatura de threshold é o random desejado. As propriedades criptográficas das assinaturas BLS atendem aos requisitos de qualidade do random, a parte de threshold protege contra o "last-actor", e a combinabilidade única das chaves permite implementar muitos algoritmos interessantes que possibilitam, por exemplo, agregar mensagens de protocolo de forma eficiente.

Portanto, se você está construindo PVRB em sua blockchain, é muito provável que você chegue ao esquema de assinaturas BLS com threshold, já utilizado por vários projetos. Por exemplo, DFinity (aqui benchmark que implementa o esquema, e aqui exemplo de implementação de verifiable secret sharing), ou Keep.network (aqui está seu random beacon yellowpaper, e aqui está exemplo do contrato inteligente que atende ao protocolo).

Implementação de PVRB

Infelizmente, ainda não vemos um protocolo implementado nas blockchains PVRB que tenha demonstrado sua segurança e resiliência. Embora os protocolos em si estejam prontos, sua aplicação técnica a soluções existentes é complicada. Para sistemas centralizados, o PVRB não faz sentido, enquanto os descentralizados estão severamente limitados em todos os recursos computacionais: CPU, memória, armazenamento, I/O. O design do PVRB consiste na combinação de diferentes protocolos para tentar criar algo que atenda a todos os requisitos de pelo menos um blockchain viável. Um protocolo calcula de forma mais eficiente, mas requer mais mensagens entre RPs, enquanto outro requer muito poucas mensagens, mas a criação de uma prova pode ser uma tarefa que leva dezenas de minutos ou até horas.

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

• Resistência criptográfica. Seu PVRB deve ser estritamente imparcial, sem a possibilidade de controle de um único bit. Em alguns esquemas, isso não é verdade, então chame um criptógrafo.
• Problema do "último ator". Seu PVRB deve ser resistente a ataques em que um atacante, controlando um ou mais RPs, pode escolher uma das duas opções de resultado.
• Problema de sabotagem do protocolo. Seu PVRB deve ser resistente a ataques em que um atacante, controlando um ou mais RPs, decide se deve ou não haver aleatoriedade e pode garantir, ou com uma probabilidade determinada, influenciar isso.
• Problema da quantidade de mensagens. Seus RPs devem enviar o mínimo possível de mensagens para a blockchain e evitar ações síncronas, como situações em que "enviei uma informação e estou esperando uma resposta de um participante específico". Em redes P2P, especialmente geograficamente dispersas, não se deve contar com uma resposta rápida.
• Problema da complexidade computacional. A verificação de qualquer etapa do PVRB on-chain deve ser extremamente fácil, visto que é realizada por todos os clientes completos da rede. Se a implementação for feita por meio de um contrato inteligente, as exigências de velocidade são muito rigorosas.
• Problema de disponibilidade e continuidade. Seu PVRB deve buscar ser resistente a situações em que parte da rede se torna indisponível por algum tempo e parte dos RPs simplesmente para de funcionar.
• Problema de configuração confiável e distribuição inicial de chaves.. Se o seu PVRB utiliza um protocolo de configuração primário, essa é uma história separada, grande e séria. Aqui está exemplo. Se os participantes precisam se informar sobre suas chaves antes de iniciar o protocolo, isso também é um problema, especialmente se a composição dos participantes mudar
• Problemas de desenvolvimento. A disponibilidade de bibliotecas nas linguagens necessárias, sua segurança e desempenho, a publicidade, testes complexos, etc.

Por exemplo, com assinaturas BLS de threshold, há um problema significativo: antes de começar a trabalhar, os participantes precisam trocar chaves entre si, organizando um grupo no qual o threshold funcionará. Isso significa que será necessário aguardar pelo menos uma rodada de troca em uma rede descentralizada, e considerando que a aleatoriedade gerada, por exemplo, é necessária em jogos em tempo real, isso significa que o sabotagem do protocolo é possível nesta fase e as vantagens do esquema de threshold se perdem. Este problema é mais simples do que os anteriores, mas ainda requer o desenvolvimento de um procedimento separado para a formação de grupos de threshold, que precisará ser protegido economicamente, através de depósitos e penalidades (slashing) para os participantes que não seguirem o protocolo. Além disso, a verificação de BLS com um nível aceitável de segurança simplesmente não se encaixa, por exemplo, em uma transação padrão da EOS ou Ethereum — simplesmente não há tempo suficiente para a verificação. O código dos contratos é WebAssembly ou EVM, executado por uma máquina virtual. As funções criptográficas não são implementadas nativamente (ainda), e operam dezenas de vezes mais devagar do que bibliotecas criptográficas normais. Muitos protocolos não atendem aos requisitos simplesmente com base no volume de chaves, por exemplo, são 1024 e 2048 bits para RSA, 4 a 8 vezes mais do que a assinatura padrão de uma transação no Bitcoin e Ethereum.

A presença de implementações em várias linguagens de programação também desempenha um papel — existem poucas, especialmente para novos protocolos. A opção de integração no consenso exige que o protocolo seja escrito na linguagem da plataforma, então será necessário procurar código em Go para geth, em Rust para Parity, em C++ para EOS. O código em JavaScript precisará ser procurado por todos, e como JavaScript e criptografia não são exatamente amigos, o WebAssembly ajudará, que agora certamente se afirma como o próximo importante padrão da internet.

Conclusão

Espero que no anterior artigo Consegui convencê-lo de que a geração de números aleatórios em blockchain é criticamente importante para diversos aspectos da vida em redes descentralizadas, e neste artigo mostrei que essa tarefa é extremamente ambiciosa e desafiadora, mas já existem boas soluções. De fato, o design final do protocolo só será possível após a realização de testes extensivos que considerem todos os aspectos, desde a configuração até a simulação de falhas, portanto, é improvável que você encontre receitas prontas nos whitepapers das equipes ou em artigos, e nós, nos próximos um ou dois anos, definitivamente não nos atreveremos a escrever “façam assim, isso está absolutamente correto”.

Até agora, para o nosso PVRB no blockchain em desenvolvimento Haya, decidimos utilizar assinaturas BLS de limiar, planejamos implementar o PVRB no nível de consenso, uma vez que a verificação em contratos inteligentes com um nível aceitável de segurança ainda é impossível. É possível que utilizemos duas abordagens: primeiro uma cara divisão secreta para criar um random_seed de longo prazo, que será usado como base para a geração de aleatoriedade de alta frequência com assinaturas BLS de limiar determinísticas, ou podemos nos limitar a uma única abordagem. Dizer de antemão como será o protocolo, infelizmente, é impossível, mas é encorajador que, assim como na ciência, em tarefas de engenharia, um resultado negativo também é um resultado, e cada nova tentativa de resolver um problema é um passo a mais para a pesquisa de todos os que se ocupam dessa questão. Para atender às exigências do negócio, estamos resolvendo uma tarefa prática específica — fornecer aplicativos de jogos com uma fonte de entropia confiável, portanto, temos que prestar atenção também ao próprio blockchain, especialmente em relação à finalização da cadeia e à governança da rede.

E embora atualmente não vejamos um PVRB comprovadamente resistente em blockchains, que tenha sido usado por tempo suficiente para passar pelos testes de aplicativos reais, múltiplas auditorias, cargas de trabalho e, claro, ataques reais, o número de caminhos possíveis confirma que a solução existe, e algum desses algoritmos, no final, resolverá o problema. Teremos prazer em compartilhar os resultados e agradecemos às outras equipes que também estão lidando com essa questão por seus artigos e códigos que permitem que engenheiros não cometam os mesmos erros repetidamente.

Portanto, ao encontrar um programador projetando um randomizador descentralizado, seja cauteloso e atencioso, e forneça apoio psicológico se necessário 🙂

Fonte: habr.com