BR112020006407A2 - blockchains credenciadas por mensagem - Google Patents

Abstract

Em um sistema de transação em que transações são organizadas em blocos, um novo bloco Br de transações válidas é construído, em relação a uma sequência de blocos anteriores B0, B1,..., Br~1, ao fazer uma entidade determinar uma quantidade Q dos blocos anteriores, fazer uma entidade usar uma chave secreta a fim de computar uma série S exclusivamente associada a Q e à entidade, fazer a entidade computar a partir de S uma quantidade T que é a própria S, uma função de S e/ou valor de hash de S, fazer a entidade determinar se T possui uma dada propriedade, e, se T possuir a dada propriedade, fazer a entidade sinalizar digitalmente Br e disponibilizar S e uma versão digitalmente sinalizada de Br, em que a entidade é selecionada com base em um valor aleatório que varia de acordo com uma assinatura digital de Br.

Description

“BLOCKCHAINS CREDENCIADAS POR MENSAGEM” CAMPO DA TÉCNICA

[0001] Este pedido refere-se ao campo de transações eletrônicas e, mais particularmente, ao campo de segurança do conteúdo de sequências de blocos de transação para transações eletrônicas.

ANTECEDENTES DA INVENÇÃO

[0002] Um blockchain consiste em uma sequência aumentável de blocos: 1, 2,..., em que cada bloco consiste em diversas transações, o hash do bloco anterior e outros dados, por exemplo, o número do bloco, informações sobre tempo, etc. As propriedades úteis de um blockchain são que cada usuário no sistema eventualmente conhece o conteúdo de cada bloco, ninguém pode alterar o conteúdo ou a ordem dos blocos e qualquer transação válida eventualmente entrará em um bloco na cadeia.

[0003] Os usuários podem assinar digitalmente e, assim, cada usuário possui pelo menos uma chave pública e uma chave secreta correspondente. Em um blockchain, em geral, conhece-se as chaves públicas, mas não necessariamente o usuário que a possui. Consequentemente, pode-se identificar uma chave pública com seu proprietário.

[0004] Um blockchain funciona propagando mensagens (por exemplo, blocos, transações, etc.). Tipicamente, mas não exclusivamente, as mensagens são propagadas transmitindo-se as mesmas de uma forma par a par ou através de retransmissões.

[0005] Diversos sistemas de blockchain exibem que um bloco seja certificado por assinaturas digitais de um número suficiente de usuários no sistema. Em alguns sistemas, tais usuários certificados pertencem a um conjunto fixo de usuários. Em alguns outros sistemas, os mesmos pertencem a um conjunto dinamicamente alterado. Isso é preferencial devido ao dato de que um adversário teria dificuldade de corromper um conjunto dinamicamente alterado, particularmente se o conjunto não for apenas dinâmico, mas imprevisível também.

[0006] Uma forma particularmente eficaz de selecionar um conjunto de usuários de uma forma variável, mas imprevisível, é o sorteio criptográfico empregado pela Algorand. Aqui, um usuário i pertence a um conjunto de usuários com poder para atuar em algumas etapas s durante a produção do número de blocos r com base no resultado de uma computação que i realizada através de uma chave secreta sua, com o uso das entradas s e r, e possivelmente outras entradas e outros dados (por exemplo, o fato de que o usuário ingressou no sistema pelo menos k blocos antes do bloco r, para algum dado número inteiro k). Por exemplo, a computação de i pode envolver a assinatura digital de i , de tais entradas, hash de e verificação de se o hash é menor que um dado alvo t. (De fato, como qualquer outra série, um valor verificado por hash pode ser interpretado de alguma outra forma padrão como um número.) Se esse for o caso, então, é definido como sendo a credencial de i para a etapa 5 sobre o bloco r. Tal credencial prova a qualquer um que i te, de fato, o direito de produzir uma mensagem (de preferência, assinada) sia mensagem para a etapa s na rodada r, ou seja, no processo que visou produzir o bloco r. De fato, as assinaturas digitais de i podem ser verificadas por qualquer um, e qualquer um pode verificar por hash um dado valor e, então, verificar se o resultado é, de fato, menor que (ou igual a) um dado número. Consequentemente, i pode propagar ambos e em Algorand, a credencial é computada em relação a uma chave a longo prazo, enquanto a assinatura é computada com o uso de uma chave temporária, que i usa apenas para autenticar uma mensagem: sua mensagem .

[0007] De fato, um i honesto apaga tal chave secreta temporária assim que usa a mesma para sinalizar

[0008] Usar chaves temporárias que são apagadas após o uso impede que um adversário que corrompa i, após propagar force i a sinalizar uma mensagem diferente sobre a etapa s da rodada r. O sistema, entretanto, se baseia em um procedimento adequado para garantir a outros que é uma chave temporária de i devotada a autenticar sua mensagem para a etapa s da rodada r. Tal garantia pode exigir que dados adicionais sejam armazenados e/ou transmitidos. Seria, portanto, bom diminuir essa necessidade. Particularmente, para certificar os blocos de um blockchain.

[0009] É, assim, desejável fornecer registros públicos e sistemas de dinheiro eletrônico que não precisem confiar em uma autoridade central e não sofram a ineficiência e falta de segurança de abordagens decentralizadas conhecidas.

SUMÁRIO DA INVENÇÃO

[0010] De acordo com o sistema descrito no presente documento, em um sistema de transação em que as transações são organizadas em blocos, um novo bloco Br de transações válidas é construído, em relação a uma sequência de blocos anteriores B0, B1, . . . , Br-1, ao fazer uma entidade determinar uma quantidade Q dos blocos anteriores, fazer uma entidade usar uma chave secreta a fim de computar uma série S exclusivamente associada a Q e à entidade, fazer a entidade computar a partir de S uma quantidade T que é a própria S, uma função de S e/ou valor de hash de S, fazer a entidade determinar se T possui uma dada propriedade, e, se T possuir a dada propriedade, fazer a entidade sinalizar digitalmente Br e disponibilizar S e uma versão digitalmente sinalizada de Br, em que a entidade é selecionada com base em um valor aleatório que varia de acordo com uma assinatura digital de Br. A chave secreta pode ser uma chave de sinalização secreta correspondente a uma chave pública da entidade e S é uma assinatura digital de Q pela entidade. T pode ser um número e satisfaz a propriedade se T for menor que um dado número p. S pode ser disponibilizado tornando-se S deduzível a partir de Br. Cada usuário pode ter um balanço no sistema de transação e p pode variar para cada usuário de acordo com o balanço de cada usuário. O valor aleatório pode ser um hash da assinatura digital da entidade. A entidade pode ser selecionada se o valor aleatório estiver abaixo de um limite que é escolhido para fazer com que um número mínimo de entidades do sistema de transação possa sinalizar digitalmente Br.

[0011] Ainda de acordo com o sistema descrito no presente documento, selecionar um subconjunto de usuários em um sistema de blockchain para verificar um novo bloco Br em relação a uma sequência de blocos anteriores B0, B1, . . . , Br-x, inclui fazer com que pelo menos um dos usuários sinalize digitalmente o novo bloco Br juntamente com outras informações para produzir uma assinatura digital, fazer com que pelo menos algum dos usuários determine um valor de hash da assinatura digital, fazer com que pelo menos algum dos usuário compare o valor de hash a um limite predeterminado e fazer com que o subconjunto dos usuários disponibilize a assinatura digital para verificar o novo bloco Br em resposta ao valor de hash estar abaixo de um limite predeterminado para cada um do subconjunto dos usuários. Um usuário particular dentre os usuários pode sinalizar digitalmente o novo bloco Br apenas se o usuário particular dentre os usuários verificar as informações fornecidas no novo bloco Br. O valor predeterminado pode ser escolhido para fazer com que o subconjunto dos usuários contenha um número mínimo dos usuários. O sistema de blockchain pode ser usado em um sistema de transações em que as transações são organizadas em blocos.

[0012] De acordo, ainda, com o sistema descrito no presente documento, um blockchain pode realizar a certificação de pelo menos uma série de dados m fazendo um conjunto S de usuário verificar se m possui pelo menos uma dada propriedade, fazendo usuários sinalizarem digitalmente m, em resposta à verificação de m pelos usuários e fazendo os usuários disponibilizarem as assinaturas digitais de m que são assinaturas credenciadas de m. A assinatura digital de m pode ser credenciada se a assinatura digital satisfizer uma dada propriedade adicional. A assinatura digital de m pode satisfazer a dada propriedade adicional se um hash da assinatura digital for menor que um dado número alvo. A série de dados m pode ser certificada por pelo menos um dado número de assinaturas credenciadas de m.

[0013] De acordo, ainda, com o sistema descrito no presente documento, um software de computador, fornecido em um meio legível por computador não transitório, inclui um código executável que implanta qualquer uma das etapas descritas no presente documento.

[0014] A presente invenção dispensa chaves temporárias para certificar blocos. Tipicamente, um novo bloco é primeiramente preparado (por exemplo, proposto e/ou acordado por pelo menos alguns usuários) e, então, é certificado. Não se tem certeza de como um bloco B é preparado: o mesmo pode ser preparado em uma ou múltiplas etapas, mesmo com o uso de chaves temporárias. Entretanto, deseja-se certificar o mesmo sem se basear em chaves temporárias. A certificação de um bloco B garante que certas propriedades valiosas se apliquem ao bloco. Uma propriedade principal típica é possibilitar que um usuário, mesmo um usuário que não participou ou observou a preparação de um bloco B, verifique que B foi adicionado ao blockchain ou mesmo que B é o r-ésimo bloco no blockchain. Outra propriedade valiosa (frequentemente denominada finalização) garante que B não desaparecerá do blockchain, devido a um softfork, mesmo na presença de uma partição da rede de comunicação em que o protocolo de blockchain é executado.

[0015] Assume-se que um bloco B foi preparado, de qualquer forma e em qualquer número de etapas. Perceber que um bloco foi adequadamente preparado exige tempo e esforço e a verificação de várias evidências. Um certificado de B consiste em um dado número de assinaturas digitais de usuários com credenciais válidas. Tal certificado de B comprova que os usuários que produziram tais assinaturas participaram ou observaram a preparação de B. Pelo menos, comprova que, se uma das assinaturas digitais do certificado tiver sido produzida por um usuário honesto, então, esse usuário verificou que B foi preparado adequadamente.

[0016] No sistema da invenção, múltiplos usuários i (até mesmo todos os usuários), que viram evidência de que B foi adequadamente preparado, sinalizam digitalmente B.1 Essas assinaturas podem estar relacionadas a chaves a longo prazo (em oposição a temporárias). Tais assinaturas, entretanto, contam para a certificação de B se satisfizerem uma dada propriedade P. Na modalidade preferencial, uma assinatura digital de i de B, , SIGi(B), possui a dada propriedade se (a) seu hash (interpretado como um número) for menor que um dado alvo t, e, de preferência, se i tiver ingressado no blockchain pelo menos k blocos antes de B. Observa-se que qualquer um pode verificar a assinatura digital de i de B, computar seu hash e verificar que o resultado não é, de fato, maior que t. Adicionalmente, qualquer um pode verificar quando i ingressou no blockchain e, assim, que ingressou no blockchain pelo menos k blocos antes. Tal SIG i(B) pode ser considerado uma credencial especializada de i para B assim como um assinatura credenciada. Assim, no sistema da invenção, as credenciais estão ligadas a um bloco específico, em vez de a uma dada etapa s na produção 1 Sinalizar digitalmente uma quantidade Q inclui sinalizar digitalmente uma versão verificada por hash de Q, sinalizar digitalmente Q com outros dados. No presente documento, assume-se que a assinatura digital é tal que, para cada mensagem m, cada usuário tem uma única assinatura de m, sem importar como a chave pública pode ser escolhida.

do r-ésimo bloco. Consequentemente, um usuário i pode ter uma credencial para um dado bloco B, mas não para outro bloco B'. Em contrapartida, por exemplo, em Algorand, um usuário com uma credencial adequada para a etapa s na rodada r poderia sinalizar o que desejasse nessa etapa e rodada. Um certificado de bloco, portanto, consiste em um dado número n de assinaturas credenciadas para B. Observa-se que um bloco B pode ter mais de um certificado, se houver mais de n assinaturas credenciadas de B.

[0017] A eficiência do sistema da invenção deriva do fato de que um SIGi(B) adequado prova que tanto i certifica B quanto que i tem direito de certificar B. Em um sistema tradicional, i poderia ter que primeiramente obter uma credencial para a etapa s da rodada r em que consente em certificar B e, então, certificar B por uma assinatura separada. Assim, pelo menos duas assinaturas, em vez de uma, são necessárias e podem precisar ser armazenadas e/ou transmitidas como parte de um certificado de B. Adicionalmente, se a assinatura de i de B for temporária, poderia também ser necessária alguma prova de que a chave temporária usada era, de fato, a chave que i precisava usar apenas para a etapa s e a rodada r.

[0018] A segurança do sistema é derivada de uma escolha adequada do alvo t e do número n de assinaturas suficientes para certificar um bloco. Por exemplo, p é a porcentagem máxima de usuários maliciosos no sistema. Tipicamente, os usuários maliciosos são minoria — por exemplo, p < 1/3. Então, t e n podem ser escolhidos de modo que, com probabilidade suficientemente alta, (a) para qualquer valor de bloco possível B', haja n ou mais assinaturas credenciadas de usuários honestos para formar um certificado para B' e (b) em qualquer certificado de B', pelo menos um assinatura credenciada pertence a um usuário honesto.

[0019] Além disso, o conjunto de usuários honestos que são credenciados para certificar um bloco B é suficientemente aleatório para que um adversário não possa prever que são e corromper os mesmos antes que certifiquem o bloco. Por outro lado, após um usuário honesto i certificar um bloco B e propagar SIGi(B), o adversário não tem vantagem em corromper i. De fato, SIGi(B) já está sendo viralmente propagado por toda a rede, e o adversário não pode interromper esse processo de propagação. Em segundo lugar, se, após corromper i, o adversário forçar i a sinalizar digitalmente um bloco B’ diferente, então, SIGi(B') pode não ter um hash que é menor que t e ter uma probabilidade justa de encontrar n assinaturas digitais de B', o adversário poderia ter que corromper mais de uma fração p dos usuários.

[0020] Como parte do sistema da invenção, um usuário i pode não ter uma credencial única para B (ou nenhuma), mas também uma credencial com um peso (essencialmente uma credencial associada a diversos votos). De fato, o peso das credenciais de i para B pode depender de quanto dinheiro i tem no sistema. De fato, em vez de ter um único t para todos os usuários, cada usuário i pode ter seu próprio alvo ti que é mais alto que a mais alto quanto mais alta a quantidade de dinheiro de i. E o peso da credencial de i para B pode depender de quão pequeno é o hash de SIGi(B) em relação a ti. Para simplificar, mas sem limitação, o presente sistema continuará a ser descrito tratando um usuário i com uma credencial de peso m para B como m usuários, em que cada um tem uma credencial (peso 1) para B.

[0021] Até o momento, foi discutida a certificação de um bloco B através de um número suficiente de assinaturas credenciadas de B. De modo mais genérico, entretanto, o sistema da invenção se aplica a blockchains em que pelo menos uma dada mensagem m é certificada por um número suficiente de assinaturas digitais credenciadas de m. Tal mensagem m pode não ser um bloco, mas uma série de dados mais geral. Consequentemente, tal certificação de m pode garantir que diferentes propriedades de apliquem a m em relação àquelas aplicáveis ou desejáveis para blocos. Por exemplo, porém sem qualquer limitação, a propriedade de que m foi aprovado por uma fração suficiente de um conjunto S de usuários no sistema ou por pelo menos um usuário honesto em S. De fato, os usuários em S que têm uma assinatura credenciada de m podem formar uma amostra selecionada de modo suficientemente aleatório dos usuários em S. Assim, o fato de que um número suficiente de assinaturas credenciadas de m foi produzido indica que, com probabilidade suficientemente alta, uma dada fração de usuários em S ou pelo menos um usuário honesto em S aprova m.

[0022] Abaixo, após relembrar rapidamente o sistema Algorand tradicional, é fornecido um exemplo da modalidade preferencial, sem qualquer limitação, com base em Algorand.

BREVE DESCRIÇÃO DOS DESENHOS

[0023] As modalidades do sistema descrito no presente documento são explicadas em mais detalhes em conformidade com as figuras dos desenhos, que são brevemente descritas conforme segue.

[0024] A Figura 1 é uma representação esquemática de uma rede e estações de computação de acordo com uma modalidade do sistema descrito no presente documento.

[0025] A Figura 2 é um esquema e um resumo conceitual da primeira etapa do sistema de Algorand, em que um novo bloco de transações é proposto.

[0026] A Figura 3 é um esquema e um resumo conceitual do acordo e certificação de um novo bloco no sistema de Algorand.

[0027] A Figura 4 é um diagrama esquemático que ilustra uma árvore de Merkle e uma trajetória de autenticação para um valor contido em um de seus nós.

[0028] A Figura 5 é um diagrama esquemático que ilustra as árvores de Merkle correspondentes aos primeiros blocos construídos em uma árvore de blocos.

DESCRIÇÃO DETALHADA DE VÁRIAS MODALIDADES

[0029] O sistema descrito no presente documento fornece um mecanismo para distribuir verificação e propagação de transação de modo que nenhuma entidade seja unicamente responsável por realizar cálculos para verificar e/ou propagar informações de transação. Em vez disso, cada uma das entidades participantes compartilha os cálculos que são realizados para propagar transação de uma maneira verificável e confiável.

[0030] Em referência à Figura 1, um diagrama mostra uma pluralidade de estações de trabalho de computação 22a a 22c conectadas a uma rede de dados 24, tal como a Internet. As estações de trabalho 22a a 22c se comunicam entre si através da rede 24 para fornecer propagação e verificação de transação distribuída, conforme descrito em mais detalhes em outra parte no presente documento. O sistema pode acomodar qualquer número de estações de trabalho com capacidade para fornecer a funcionalidade descrita no presente documento, contanto que as estações de trabalho 22a a 22c possam se comunicar umas com as outras. Cada uma das estações de trabalho 22a a 22c pode realizar independentemente processamento para propagar transações a todas as outras estações de trabalho no sistema e verificar transações, conforme descrito em mais detalhes em outra parte no presente documento.

[0031] A Figura 2 resume de modo diagramático e conceitual a primeira etapa de uma rodada r no sistema de Algorand, em que cada um dentre alguns usuários selecionados propõe seu próprio candidato ao r- ésimo bloco. Especificamente, a etapa começa com os usuários no sistema, a, ... , z, individualmente passando pelo processo de sorteio criptográfico secreto, que decide quais usuários são selecionados para propor um bloco e em que cada usuário selecionado secretamente computa uma credencial que prova que o mesmo tem direito a produzir um bloco. No exemplo da Figura 2, apenas os usuários b, d e h são selecionados para propor um bloco, e suas credenciais, respectivamente, computadas são e . Cada usuário selecionado i monta seu próprio bloco proposto, , sinaliza temporariamente o mesmo (isto é, sinaliza digitalmente o mesmo com uma chave temporária, conforme explicado posteriormente) e propaga para rede juntamente com sua própria credencial. O líder da rodada é o usuário selecionado cuja credencial tem o menor hash. A figura indica o líder como sendo usuário d. Assim, seu bloco proposto, , é aquele a ser dado como entrada ao protocolo de acordo Binário.

[0032] A Figura 3 resume diagramática e conceitualmente o processo de Algorand para atingir acordo e certificação de um bloco proposto como o r-ésimo bloco oficial, Br. Visto que a primeira etapa de Algorand consiste em propor um novo bloco, esse processo começa com a segunda etapa. Essa etapa atualmente coincide com a primeira etapa do protocolo de acordo Bizantino preferencial de Algorand, BA*. Cada etapa desse protocolo é executada por um “comitê” diferente de jogadores, selecionado aleatoriamente por sorteio criptográfico secreto (não mostrado nessa figura). Consequentemente, os usuários selecionados para realizar cada etapa podem ser totalmente diferentes. O número de Etapas de BA* pode variar. A Figura 3 representa uma execução de BA* envolvendo 7 etapas: da etapa 2 de Algorand a etapa 8 de Algorand. No exemplo da Figura 3, os usuários selecionados para realizar a etapa 2 são a, e e q. Cada usuário i ∈ {a, e, q} propaga à rede sua credencial , que prova que i tem, de fato, direito de enviar uma mensagem na etapa 2 da rodada r de Algorand, e sua mensagem adequada dessa etapa, , temporariamente sinalizada. As etapas 3 a 7 não são mostradas. Na última etapa 8, a figura mostra que os usuários selecionados correspondentes b, f e x que atingiram acordo sobre Br como o bloco oficiam de rodada r propagam suas próprias assinaturas temporárias de bloco Br (juntamente, essas assinaturas certificam Br) e suas próprias credenciais, provando que têm o direito de atuar na etapa 8.

[0033] A Figura 4 ilustra esquematicamente uma árvore de Merkle e uma de suas trajetórias de autenticação. Especificamente, a Figura

4.A ilustra uma árvore de Merkle completa de profundidade 3. Cada nó x, em que x é denotado por uma série binária de comprimento ≤ 3, armazena um valor vx. Se x tiver comprimento ≤ 2, então, vx = H(vx0, vx1). Para a árvore de Merkle da Figura 4.a, a Figura 4.B ilustra a trajetória de autenticação do valor v010.

[0034] A Figura 5 ilustra esquematicamente as árvores de Merkle, correspondente aos primeiros 8 blocos construídos em uma árvore de blocos, construída dentro de uma árvore binária completa de profundidade

3. Na Figura 5.i, os nós marcados por um número inteiro pertencem à árvore de Merkle Ti. O conteúdo dos nós marcados por i (respectivamente, por i) é temporário (respectivamente, permanentes).

[0035] A descrição no presente documento foca em transações que são pagamentos e na descrição do sistema no presente documento como uma plataforma de dinheiro. Aqueles versados na técnica perceberão que o sistema descrito no presente documento pode lidar com todos os tipos de transações também.

[0036] O sistema descrito no presente documento tem um projeto muito flexível e pode ser implantado de formas diversas, mas relacionadas. Sua flexibilidade é ilustrada detalhando-se duas modalidades possíveis de seu projeto geral. A partir das mesmas, aqueles versados na técnica podem perceber como derivar todos os tipos de outras implantações também.

[0037] Para facilitar o entendimento da invenção e permitir a referência cruzada interna de suas várias partes, organizou-se sua apresentação em seções numeradas e intituladas. As primeiras seções são comuns a ambas as modalidades detalhadas.

1 INTRODUÇÃO

[0038] O dinheiro está se tornando crescentemente virtual. Foi estimado que cerca de 80% dos dólares americanos de hoje apenas existem como entradas de registro. Outros instrumentos financeiros estão seguindo o exemplo.

[0039] Em um mundo ideal, em que poderia se contar com uma entidade central universalmente confiável, imune a todos os ataques cibernéticos possíveis, dinheiro e outras transações financeiras poderiam ser apenas eletrônicas. Infelizmente, não se vive em tal mundo. Consequentemente, criptomoedas decentralizadas, tal como Bitcoin, e sistemas de “contrato inteligente”, tal como Ethereum, foram propostos. No centro desses sistemas está um registro compartilhado que registra confiavelmente uma sequência de transações, tão variadas como pagamentos e contratos, de uma forma inviolável. A tecnologia de escolha para garantir tal inviolabilidade é o blockchain. Os blockchains estão por trás de aplicações, tais como as criptomoedas, aplicações financeiras e a Internet das Coisas. Diversas técnicas para gerenciar registros baseados em blockchain foram propostos: prova de trabalho, prova de participação, tolerância a falha bizantina prática ou alguma combinação.

[0040] Atualmente, entretanto, os registros podem ser ineficientes para gerenciamento. Por exemplo, a abordagem de prova de trabalho da Bitcoin exige uma vasta quantidade de computação, é dispendiosa e ruim de escalonas. Adicionalmente, a mesma, de fato, concentra poder nas mãos de poucos.

[0041] Deseja-se, portanto, apresentar um novo método para implantar um registro público que oferece a conveniência e a eficiência de um sistema centralizado executado por uma autoridade confiável e inviolável, sem as ineficiências e fraquezas das implantações decentralizadas atuais. A presente abordagem é chamada de Algorand, devido ao fato de que é usada aleatoriedade algorítmica para selecionar, com base no registro construído até o momento, um conjunto de verificadores que são responsáveis por construir o bloco seguintes de transações válidas. Naturalmente, garante-se que tais seleções são provavelmente imunes a manipulações e imprevisíveis até o último minuto, mas também que são por fim universalmente claras.

[0042] A abordagem de Algorand é bastante democrática, no sentido de que nem a princípio nem fato cria diferentes classes de usuários (como “mineradores” e “usuários comuns” em Bitcoin). Em Algorand, “todo poder reside no conjunto de todos os usuários”.

[0043] Uma propriedade notável de Algorand é que seu histórico de transação pode bifurcar-se apenas com probabilidade muito baixa (por exemplo, uma em um trilhão, ou seja, até mesmo 10-18). Algorand pode também solucionar algumas preocupações legais e políticas.

[0044] A abordagem de Algorand se aplica a blockchains e, de modo mais genérico, a qualquer método para gerar uma sequência inviolável de blocos. Apresenta-se, realmente, um novo método — alternativo a e mais eficiente que blockchains — que pode ser de interesse independente.

1.1 SUPOSIÇÃO DE BITCOIN E PROBLEMAS DA TÉCNICA

[0045] Bitcoin é um sistema muito engenhoso e tem inspirado uma grande quantidade de pesquisa subsequente. No entanto, é também problemático. Serão resumidas sua suposição subjacente e problemas técnicos — que são realmente compartilhados por essencialmente todas as criptomoedas que, como a Bitcoin, são baseadas em prova de trabalho.

[0046] Para esse resumo, é suficiente lembrar que, na Bitcoin, um usuário pode possuir múltiplas chaves públicas de um esquema de assinatura digital, que o dinheiro está associado a chaves públicas e que um pagamento é uma assinatura digital que transfere alguma quantidade de dinheiro de uma chave pública para outra. Essencialmente, a Bitcoin organiza todos os pagamentos processados em uma cadeia de blocos, Β1, Β2, . . ., em que cada um consiste em múltiplos pagamentos, de modo que todos os pagamentos de B1, considerados em qualquer ordem, seguidos por aqueles de B2, em qualquer ordem, etc., constituam uma sequência de pagamentos válidos. Cada bloco é gerado, em média, a cada 10 minutos.

[0047] Essa sequência de blocos é uma cadeia, devido ao fato de que é estruturada de modo a garantir que qualquer alteração, mesmo em um único bloco, se difunda em todos os blocos subsequentes, tornando mais fácil observar qualquer alteração do histórico de pagamento. (Conforme pode ser visto, isso é atingido incluindo-se em cada bloco um hash criptográfico do bloco anterior.) Tal estrutura de bloco é denominada um blockchain.

[0048] Suposição: Maioria Honesta de Potência Computacional A Bitcoin supõe que nenhuma entidade maliciosa (nem uma coalizão de entidades maliciosas coordenadas) controla a maior parte da potência computacional devotada à geração de bloco. Tal entidade, de fato, poderia ter capacidade de modificar o blockchain e, assim, reescrever o histórico de pagamento, conforme desejar. Em particular, poderia realizar um pagamento obter os benefícios pagos e, então, “apagar” qualquer traço de .

[0049] Problema da Técnica 1: Resíduo Computacional A abordagem de prova de trabalho da Bitcoin para geração de bloco exige uma quantidade extraordinária de computação. Atualmente, com apenas algumas centenas de chaves públicas no sistema, os 500 supercomputadores mais potentes podem apenas exibir meros 12,8% por cento da potência computacional total necessária pelos jogadores de Bitcoin. Essa quantidade de computação poderia aumentar grandemente, significativamente mais usuários poderiam ingressar no sistema.

[0050] Problema da Técnica 2: Concentração de Potência Hoje, devido à quantidade exorbitante de computação necessária, espera-se que um usuário, tentando gerar um novo bloco com o uso de um computador do tipo desktop comum (sobretudo um telefone celular), perca dinheiro. De fato, para computar um novo bloco com um computador comum, o custo esperado da eletricidade necessária para alimentar a computação excede a recompensa esperada. Apenas usando grupos de computadores especialmente construídos (que não fazem nada além de “minar novos blocos”), seria esperado produzir um lucro gerando-se novos blocos. Consequentemente, atualmente há, de fato, duas classes separados de usuários: usuários comuns, que realizam apenas pagamentos, e grupos de mineração especializados, que apenas buscam novos blocos.

[0051] Não deve surpreender que, recentemente, a potência de computação total para geração de bloco se encontra dentro de apenas cinco grupos. Em tais condições, a suposição de que a maior parte da potência computacional é honesta se torna menos crível.

[0052] Problema da Técnica 3: Ambiguidade Em Bitcoin, o blockchain não é necessariamente exclusivo. De fato, sua última porção frequentemente se bifurca: o blockchain pode ser — por exemplo — de acordo com um usuário e de acordo com outro usuário. Apenas após diversos blocos terem sido adicionados à cadeia, pode-se ter razoavelmente certeza de que os primeiros blocos de serão iguais para todos os usuários. Assim, não se pode contar imediatamente com os pagamentos contidos no último bloco da cadeia. É mais prudente esperar e observar se o bloco se torna suficientemente profundo no blockchain e, assim, suficientemente estável.

[0053] Separadamente, preocupações quanto à aplicação da lei e política monetária também surgiram sobre a Bitcoin.2 2 O (pseudo) anonimato oferecido por pagamentos com Bitcoin pode ser mal utilizado para lavagem de dinheiro e/ou o financiamento de criminosos ou organizações terroristas. As cédulas ou barras de ouro tradicionais, que a princípio

1.2 ALGORAND, EM UM RESUMO

[0054] O ambiente Algorand funciona em um ambiente muito difícil. Em resumo,

[0055] (a) Ambientes Sem Permissão e Com Permissão. Algorand funciona de modo eficiente e seguro em um ambiente totalmente sem permissão, em que é permitido arbitrariamente que muitos usuários ingressem no sistema a qualquer momento, sem qualquer veto ou permissão de qualquer tipo. Obviamente, Algorand funciona ainda melhor em um ambiente com permissão.

[0056] (b) Ambientes Muito Adversos. Algorand resiste a um adversário muito forte, que pode

[0057] (1) corromper instantaneamente qualquer usuário que desejar, a qualquer momento que desejar, contanto que, em um ambiente sem permissão, 2/3 do dinheiro no sistema pertença a um usuário honesto. (Em um ambiente com permissão, independente de dinheiro, é suficiente que 2/3 dos usuários sejam honestos.)

[0058] (2) controlar totalmente e coordenar perfeitamente todos os usuários corrompidos; e

[0059] (3) programar a entrega de todas as mensagens, contanto que cada mensagem m enviada por um usuário honesto atinja todos (ou suficientemente muitos dos) os usuários honestos dentro de um tempo λm, que depende apenas do tamanho de m.

[0060] Propriedades Principais a Despeito da presença de oferecem anonimato perfeito, podem impor algum desafio, porém a fisicalidade dessas moedas retarda substancialmente as transferências de dinheiro, de modo a permitir algum grau de monitoramento por agências de aplicação da lei. A capacidade de "imprimir dinheiro” é um dos poderes mais básicos de uma nação. A princípio, portanto, a adoção massiva de uma moeda independentemente flutuante pode restringir esse poder. Atualmente, entretanto, a Bitcoin está longe de ser uma ameaça às políticas monetárias governamentais em devido a seus problemas de escalabilidade, podem nunca ser.

adversário forte, em Algorand

[0061] • A quantidade de computação necessária é mínima. Essencialmente, não importa quantos usuários estão presentes no sistema, cada um dos mil e quinhentos usuários precisa realizar no máximo alguns segundos de computação.

[0062] • Um novo bloco é gerado rapidamente e, de fato, nunca deixará o blockchain. Ou seja, o blockchain de Algorand pode se bifurcar apenas com probabilidade desprezível (isto é, menos de um em um trilhão ou 10-18). Assim, os usuários podem retransmitir os pagamentos contidos em um novo bloco assim que o bloco aparecer.

[0063] • Todo poder está com os próprios usuários. Algorand é um sistema realmente distribuído.

[0064] Em particular, não há entidades exógenas (como os “mineradores” em Bitcoin), que podem controlar quais transações são reconhecidas. TÉCNICAS DE ALGORAND.

[0065] 1. UM PROTOCOLO DE ACORDO BIZANTINO NOVO E RÁPIDO. Algorand gera um novo bloco através de um protocolo de acordo bizantino (ΒΑ) binário, de passagem de mensagem, criptográfico da invenção, BA*. O protocolo BA* não apenas satisfaz algumas propriedades adicionais (que serão discutidas logo), mas é também muito rápido. De modo geral, sua versão de entrada binária consiste em um circuito de 3 etapas, em que um jogador i envia uma única mensagem mi a todos os outros jogadores. Executado em uma rede completa e sincronizada, com mais de 2/3 dos jogadores sendo honestos, com probabilidade > 1/3, após cada circuito do protocolo terminar em acordo. (Enfatiza-se que o protocolo BA* satisfaz a definição original de acordo bizantino, sem quaisquer enfraquecimentos.)

[0066] Algorand alavanca esse protocolo BA binário para atingir acordo, no presente modelo de comunicação diferente, em cada novo bloco. O acordo sobre o bloco é, então, certificado, através de um número prescrito de assinatura digital dos verificadores adequados e propagado através da rede.

[0067] 2. SORTEIO CRIPTOGRÁFICO SECRETO. Embora muito rápido, o protocolo BA* poderia se beneficiar de velocidade adicional quando executado por milhões de usuários. Consequentemente, Algorand escolhe jogadores de BA* para serem um subconjunto muito menor do conjunto de todos os usuários. Para evitar um tipo diferente de problema de concentração de potência, cada novo bloco Br será construído e acordado, através de uma nova execução de BA*, por um conjunto separado de verificadores selecionados, SVr. A princípio, selecionar tal conjunto pode ser tão difícil quanto selecionar Br diretamente. Esse problema é solucionado por uma abordagem inovadora chamada sorteio criptográfico secreto. O sorteio na prática de selecionar oficiais aleatoriamente dentre um conjunto grande de indivíduos elegíveis. (O sorteio foi praticado por séculos: por exemplo, pelas repúblicas de Atena, Florença e Veneza. Nos sistemas judiciais modernos, a seleção aleatória é frequentemente usada para escolher juris. A amostragem aleatória também tem sido defendida para eleições.) Em um sistema decentralizado, obviamente, escolher as moedas aleatórias para selecionar aleatoriamente os membros de cada conjunto de verificadores SVr é problemático. Recorre-se, assim, à criptografia a fim de selecionar cada conjunto de verificadores, dentre a população de todos os usuários, de uma forma que seja automática de modo garantido (isto é, sem exigir troca de mensagens) e aleatória. De uma forma similar, seleciona-se um usuário, o líder, responsável por propor o novo bloco Br, e o conjunto de verificadores SVr, responsável por atingir o acordo no bloco proposto pelo líder. O sistema da invenção alavanca algumas informações, Qr-1, que são deduzíveis a partir do conteúdo do bloco anterior e são não manipuláveis mesmo na presença de um adversário muito forte.

[0068] 3. A QUANTIDADE (SEMENTE) Qr. Usa-se o último bloco Br-1 no blockchain a fim de determinar automaticamente o conjunto de verificadores seguinte e líder responsável por construir o novo bloco Br. O desafio dessa abordagem é que, apenas escolher um pagamento ligeiramente diferente da rodada anterior, o adversário forte ganha um controle enorme sobre o líder seguinte. Mesmo se tiver controlado apenas 1/1.000 dos jogadores/dinheiro no sistema, poderia garantir que todos os líderes fossem maliciosos. (Consultar a Seção de Intuição 4.1.) Esse desafio é central a todas as abordagens de prova de participação e, até onde se sabe, o mesmo não foi, até agora, satisfatoriamente solucionado.

[0069] Para atender esse desafio, foi propositadamente construída e continuamente atualizada uma quantidade cuidadosamente definida, Qr, que provavelmente não é apenas imprevisível, mas também não é influenciável, pelo adversário forte. Qr pode ser denominado a r-ésima semente, já que é a partir de Qr que Algorand seleciona, através de um sorteio criptográfico secreto, todos os usuários que exercem um papel especial na geração do r-ésimo bloco. A semente Qr será deduzível a partir do bloco Br-1.

[0070] 4. CREDENCIAIS SECRETAS. Usar de modo aleatório e não ambíguo o último bloco atual, Br-1, a fim de escolher o conjunto de verificadores e o líder responsável por construir o novo bloco, Br, não é suficiente. Visto que Br-1 precisa ser conhecido antes de gerar Br, a última quantidade não influenciável Qr-1 deduzível de Br-1 também precisa ser conhecida. Consequentemente, também o são os verificadores e o líder responsável por computar o bloco Br. Assim, o adversário forte pode corromper imediatamente todos os mesmos, antes de entrar em qualquer discussão sobre Br, de modo a obter controle completo sobre o bloco que certificam.

[0071] Para evitar esse problema, líderes (e na realidade verificadores também) aprendem secretamente seu papel, mas podem computar uma credencial adequada, que pode fornecer todos que, de fato, têm esse papel. Quando um usuário privadamente percebe que é o líder para o bloco seguinte, em primeiro lugar, monta secretamente seu próprio novo bloco proposto e, então, dissemina o mesmo (de modo que possa ser certificado) juntamente com sua própria credencial. Dessa forma, embora o adversário perceba imediatamente quem é o líder do bloco seguinte e embora possa corromper o mesmo imediatamente, será também tarde demais para o adversário influenciar a escolha de um novo bloco. De fato, o mesmo não pode “recuperar” a mensagem do líder tanto quanto um governo forte pode colocar de volta na garrafa uma mensagem viralmente espalhada pelo WikiLeaks.

[0072] Como pode ser visto, não se pode garantir a exclusividade do líder, nem que ninguém com certeza sabe quem é o líder, incluindo o próprio líder! Mas, em Algorand, o progresso não ambíguo será garantido.

[0073] 5. SUBSTITUIBILIDADE DO JOGADOR. Após propor um novo bloco, o líder pode também “morrer” (ou ser corrompido pelo adversário), devido ao fato de que seu trabalho foi concluído. Mas, para os verificadores em SVr, é menos simples. De fato, sendo responsável por certificar o novo bloco Br com assinaturas suficientes, os mesmos precisam primeiramente executar o acordo bizantino no bloco proposto pelo líder. O problema é que, não importa quão eficiente seja, BA* exige múltiplas etapas e a honestidade de > 2/3 de seus jogadores. Isso é um problema devido ao fato de que, por razões de eficiência, o conjunto de jogadores de BA* consiste no pequeno conjunto SVr aleatoriamente selecionado dentre o conjunto de todos os usuários. Assim, o adversário forte, embora incapaz de corromper 1/3 de todos os usuários, pode certamente corromper todos os membros de SVr.

[0074] Felizmente, será provado que o protocolo BA*, executado propagando-se mensagens de uma forma par a par, é substituível por jogador. Esse requisito inovador significa que o protocolo atinge correta e eficientemente consenso mesmo se cada uma de suas etapas for executada por um conjunto de jogadores totalmente novo, selecionado de modo aleatório e independente. Assim, com milhões de usuários, cada pequeno conjunto de jogadores associados a uma etapa de BA* mais provavelmente tem intersecção vazia com o conjunto seguinte.

[0075] Adicionalmente, as etapas de jogadores de etapas diferentes de BA* terão provavelmente cardinalidade totalmente diferente. Além disso, os membros de cada conjunto não sabem qual será o conjunto seguinte de jogadores e não passam secretamente qualquer estado interno.

[0076] A propriedade de jogador substituível é realmente essencial para derrotar o adversário dinâmico e muito forte enfrentado. Acredita-se que protocolos de jogador substituível serão provados essenciais em muitos dos contextos e aplicações. Em particular, os mesmos serão essenciais para executar com segurança pequenos subprotocolos incorporados em um universo maior com um adversário dinâmico, que, sendo capaz de corromper mesmo uma pequena fração dos jogadores totais, não tem dificuldade de corromper todos os jogadores no subprotocolo menor.

[0077] Uma Propriedade/Técnica Adicional: Honestidade Preguiçosa Um usuário honesto segue suas instruções prescritas, que incluem estar online e executar o protocolo. Visto que Algorand tem requisito de comunicação e computação apenas modesta, estar online e executar o protocolo “no plano de fundo” não é um grande sacrifício. Obviamente, algumas “ausências” entre jogadores honestos, como aqueles devido à perda repentina de conectividade e a necessidade de reiniciar, são automaticamente toleradas (devido ao fato de que se pode sempre considerar tal alguns jogadores como sendo temporariamente maliciosos).

Destaca-se, entretanto, que Algorand pode ser simplesmente adaptado de modo a funcionar em um novo modelo, em que usuários honestos estão offline a maior parte do tempo. Outro novo modelo pode ser informalmente introduzido conforme segue.

[0078] Honestidade Preguiçosa. De modo geral, um usuário i é preguiçoso mais honesto se (1) seguir todas suas instruções prescritas, quando é solicitado que participe do protocolo, e (2) for solicitado que participe do protocolo apenas raramente, com um aviso antecipado adequado.

[0079] Com tal noção relaxada de honestidade, pode-se ter ainda mais confiança de que pessoas honestas estarão disponíveis quando necessário, e Algorand garante que, quando esse for o caso,

[0080] O sistema opera com segurança mesmo se, em um dado ponto no tempo, a maior parte dos jogadores participantes é maliciosa. 2 PRELIMINARES

2.1 PRIMITIVAS CRIPTOGRÁFICAS

[0081] Verificação por Hash Ideal. Baseia-se em uma função de hash criptográfico computável eficientemente, H, que mapeia arbitrariamente longas séries a séries binárias de comprimento fixo. Seguindo uma longa tradição, modela-se H como um oráculo aleatório, essencialmente uma função que mapeia cada série possível s a uma série binária selecionada aleatória e independentemente (e, então, fixa), H(s), do comprimento escolhido.

[0082] Nas presentes modalidades descritas, H tem saídas de 256 bits de comprimento. De fato, tal comprimento é curto o suficiente para tornar o sistema eficiente e longo o suficiente para tornar o sistema seguro. Por exemplo, deseja-se que H seja resistente à colisão. Ou seja, pode ser difícil encontrar duas séries diferentes x e y, de modo que H(x) = H(y). Quando H é um oráculo aleatório com saídas de 256 bits de comprimento,

encontrar qualquer tal par de séries é, de fato, difícil. (Tentar aleatoriamente e se basear no paradoxo de aniversário, poderia exigir 2256/2 = 2128 testes.)

[0083] Sinalização Digital. As assinaturas digitais permitem que os usuários autentiquem informações uns com os outros sem compartilhar quaisquer chaves secretas. Um esquema de assinatura digital consiste em três algoritmos rápidos: um gerador de chave probabilístico G, um algoritmo de sinalização S e um algoritmo de verificação V.

[0084] Dado um parâmetro de segurança k, um número inteiro suficientemente alto, um usuário i usa G para produzir um par de chaves de k bits (isto é, séries): uma chave “pública” pki e uma chave de sinalização “secreta” correlacionada ski. Essencialmente, uma chave pública não “trai” sua chave secreta correspondente. Ou seja, mesmo dado conhecimento de pki, ninguém além de i pode computar ski em menos que um tempo astronômico.

[0085] O usuário i usa ski para sinalizar digitalmente as mensagens. Para cada mensagem possível (série binária) m, i primeiramente verifica por hash m e, então, executa o algoritmo S nas saídas H(m) e ski de modo a produzir a série de k bits.

3

[0086] A série binária é denominada assinatura digital de i de m (em relação a pki) e pode ser mais simplesmente denotada por sigi(m), quando a chave pública pki está clara a partir do contexto.

[0087] Todos que conhecem pki podem usar o mesmo para verificar as assinaturas digitais produzidas por i. Especificamente, nas saídas (a) a chave pública pki de um jogador i, (b) uma mensagem m e (c) uma série s, ou seja, a suposta assinatura digital de i da mensagem m, o algoritmo de 3 Visto que H é resiliente à colisão, é praticamente impossível que, assinando-se m, "assine-se acidentalmente" uma mensagem diferente verificação V emite SIM ou NÃO.

[0088] As propriedades necessárias a partir de um esquema de assinatura digital são:

[0089] 1. Assinaturas legitimadas são sempre verificadas: Se s = sigi(m), então, V(pki, m, s) = SIM; e

[0090] 2. As assinaturas digitais são difíceis de forjar: Sem conhecimento de ski, o tempo para encontrar uma série s, de modo que V(pki, m, s) = SIM, para uma mensagem m nunca assinada por i, é astronomicamente longo.

[0091] (Seguindo fortes requisitos de segurança, isso é verdadeiro mesmo se alguém puder obter a assinatura de qualquer outra mensagem.)

[0092] Consequentemente, para impedir que qualquer outro sinalize as mensagens a seu favor, um jogador i precisa manter sua chave de sinalização secreta (portanto, o termo “chave secreta”) e possibilitar que qualquer um verifique as mensagens que assina, i tem um interesse em tornar pública sua chave pki (portanto, o termo “chave pública”).

[0093] Assinaturas com Recuperabilidade de Mensagem Em geral, uma mensagem m não é recuperável a partir de sua assinatura sigi(m). A fim de lidar virtualmente com as assinaturas digitais que satisfazem a propriedade de “recuperabilidade de mensagem” conceitualmente conveniente (isto é, garantir que o assinante e a mensagem são facilmente computáveis a partir de uma assinatura, define-se

[0094] Sinalização Digital Exclusiva. Considera-se também esquemas de assinatura digital (G, S, V) que satisfazem a propriedade adicional a seguir.

[0095] 3. Exclusividade. É difícil encontrar séries pk', m, s e s', de modo que

[0096] (Observa-se que a propriedade de exclusividade se mantém também para as séries pk' que não são chaves públicas legitimamente geradas. Em particular, entretanto, a propriedade de exclusividade implica que, se alguém usou o gerador de chave específico G para computar um chave pública pk juntamente com uma chave secreta correlacionada sk e, assim, sabia sk, poderia ser essencialmente impossível também para ele encontrar duas assinaturas digitais diferentes de uma mesma mensagem em relação a pk.)

OBSERVAÇÕES

[0097] • DE ASSINATURAS EXCLUSIVAS A FUNÇÕES ALEATÓRIAS VERIFICÁVEIS. Em relação a um esquema de assinatura digital com a propriedade de exclusividade, o mapeamento m → H(sigi(m)) associa a cada série possível m uma série de 256 bits, aleatoriamente selecionada, exclusiva e a exatidão desse mapeamento pode ser provada dada a assinatura sigi(m).

[0098] Ou seja, a verificação por hash ideal e o esquema de assinatura digital que satisfazem a propriedade de exclusividade fornecem uma implantação elementar de uma função aleatória verificável (VRF).

[0099] Uma VRF é um tipo especial de assinatura digital. Pode-se escrever VRFi(m) para indicar tal assinatura especial de i de uma mensagem m. Adicionalmente a satisfazer a propriedade de exclusividade, as funções aleatórias verificáveis produzem saídas que são garantidas como sendo suficientemente aleatórias. Ou seja, o VRFi(m) é essencialmente aleatório e imprevisível até ser produzido. Em contrapartida, SIGi(m) não precisa ser suficientemente aleatório. Por exemplo, o usuário i pode escolher sua chave pública de modo que SIGi(m) sempre seja uma série de k bits que é (lexicograficamente) pequena (isto é, cujos primeiros poucos bits poderiam ser sempre 0s). Nota-se, no entanto, que, visto que H é uma função de hash ideal, H(SIGi(m)) será sempre uma série de 256 bits aleatória. Nas modalidades preferenciais, faz-se uso extensivo de assinaturas digitais de verificação por hash que satisfazem a propriedade de exclusividade precisamente para poder associada a cada mensagem m e cada usuário i um número aleatório exclusivo. Se for implantado Algorand com VRFs, pode- se substituir H(SIGi(m)) por VRFi(m). Em particular, um usuário i não precisa computar primeiramente SIGi(m), então, H(SIGi(m)) (afim, — por exemplo — de comparar H(SIGi(m)) com um número p). Pode-se computar diretamente VRFi(m). Em suma, deve-se compreender que H(SIGi(m)) pode ser interpretado como VRFi(m) ou como um número suficientemente aleatório, facilmente computado pelo jogador i, mas imprevisível para outros, associado de modo não ambíguo a i e m.

[00100] • TRÊS NECESSIDADES DIFERENTES PARA ASSINATURAS DIGITAIS. Em Algorand, um usuário i baseia-se em assinaturas digitais para

[00101] (1) Autenticar pagamentos próprios de i. Nessa aplicação, as chaves podem ser “a longo prazo” (isto é, usadas para sinalizar muitas mensagens durante um período de tempo) e se originam de um esquema de assinatura comum.

[00102] (2) Gerar credenciais que provam que i tem o direito de atuar em alguma etapa s de uma rodada r. Aqui, as chaves podem ser a longo prazo, mas precisam ser originadas de um esquema que satisfaz a propriedade de exclusividade.

[00103] (3) Autenticar a mensagem i enviada em cada etapa em que atua. Aqui, as chaves precisam ser temporárias (isto é, destruídas após seu primeiro uso), mas podem se originar em um esquema de assinatura comum.

[00104] • UMA SIMPLIFICAÇÃO DE CUSTO PEQUENO. Por uma questão de simplicidade, prevê-se que cada usuário i tenha uma chave a longo prazo única. Consequentemente, tal chave precisa se originar de um esquema de assinatura com a propriedade de exclusividade. Tal simplicidade tem um custo computacional pequeno. Tipicamente, de fato, as assinaturas digitais exclusivas são ligeiramente mais dispendiosas de produzir e verificar do que assinaturas comuns.

2.2 O REGISTRO PÚBLICO IDEALIZADO

[00105] Algorand tenta imitar o sistema de pagamento a seguir, com base em um registro público idealizado.

[00106] 1. O Estado Inicial. O dinheiro está associado a chaves públicas individuais (privadamente geradas e pertencentes aos usuários). pk1, . . . ,pkj são as chaves públicas iniciais e a1, . . . , aj, suas respectivas quantidades iniciais de unidades monetárias, então, o estado inicial é

[00107] que é assumido como sendo conhecimento comum no sistema.

[00108] 2. Pagamentos. pk é uma chave pública que tem atualmente α ≥ 0 unidades monetárias, pk' outra chave pública e a' um número não negativo não maior que a. Então, um pagamento (válido) é uma assinatura digital, relacionada a pk, que especifica a transferência de a' unidades monetárias de pk para pk', juntamente com algumas informações adicionais. Nos símbolos,

[00109] em que I representa quaisquer informações adicionais consideradas úteis, mas não sensíveis (por exemplo, informações de tempo e um identificador de pagamento), e I quaisquer informações adicionais consideradas sensíveis (por exemplo, a razão para o pagamento, possivelmente as identidades os proprietários de pk e pk' e assim por diante).

[00110] Denomina-se pk (ou seu proprietário) o pagador, cada pk' (ou seu proprietário) um beneficiário e a' como a quantidade do pagamento

[00111] Ingresso Livre Através de Pagamentos. Observa-se que os usuários podem ingressar no sistema sempre que quiserem gerando seus próprios pares de chave pública/secreta. Consequentemente, a chave pública pk' que aparece no pagamento acima pode ser uma chave pública recém-gerada que nunca “possuiu” qualquer dinheiro antes.

[00112] 3. O Registro Mágico. No Sistema Idealizado, todos os pagamentos são válidos e aparecem em uma lista inviolável L de conjuntos de pagamentos “postados no céu” para todos verem:

[00113] Cada bloco PAYr+1 consiste no conjunto de todos os pagamentos realizados desde o aparecimento do PAYr. No ideal sistema, um novo bloco aparece após uma quantidade de tempo fixa (ou finita).

[00114] Discussão.

[00115] ● Pagamentos Mais Gerais e Saída de Transação Não Gasta. De modo mais genérico, se uma chave pública pk possui uma quantidade a, então, um pagamento válido de pk pode transferir as quantidades respectivamente para as chaves contanto que

[00116] Em Bitcoin e sistemas similares, o dinheiro possuído por uma chave pública pk é segregado em quantidades separadas, e um pagamento realizado por pk precisa transferir tal quantidade segregada a em sua totalidade. Se pk desejar transferir apenas uma fração a' < a de a para outra chave, então, precisa também transferir o balanço, a saída de transação não gasta, para outra chave, possivelmente o próprio pk.

[00117] Algorand também funciona com chaves que têm quantidades segregadas. Entretanto, a fim de focar nos aspectos inovadores de Algorand, é conceitualmente mais simples aderir às presentes formas mais simples de pagamentos e chaves que têm uma quantidade única associada às mesmas.

[00118] ● Estado Atual. O Esquema Idealizado não fornece diretamente informações sobre o estado atual do sistema (isto é, sobre quantas unidades monetárias cada chave pública tem). Estas informações são deduzíveis a partir do Registro Mágico.

[00119] No sistema ideal, um usuário ativo continuamente armazena e atualiza as últimas informações de estado ou teria que reconstruir de outro modo as mesmas, a partir do zero ou a partir da última vez que computou as mesmas. (Ademais, adiante mostra-se como aumentar Algorand de modo a possibilitar que seus usuários reconstruam o estado atual de uma maneira eficiente.)

[00120] ● Segurança e “Privacidade”. As assinaturas digitais garantem que ninguém possa forjar um pagamento de outro usuário. Em um pagamento as chaves públicas e a quantidade não estão ocultas, mas as informações sensíveis I estão. De fato, apenas H(I) aparece em e, visto que H é uma função de hash ideal, H(I) é um valor de 256 bits aleatório e, assim, não há como imaginar o que I era, além de simplesmente imaginar. Além disso, para provar o que I era (por exemplo, para provar a razão do pagamento), o pagador pode apenas revelar I. A exatidão do I revelado pode ser verificada computando-se H(I) e comparando-se o valor resultante com o último item de . De fato, visto que H é resiliente à colisão, é difícil encontrar um segundo valor I' de modo que H(I) = H(I').

2.3 NOÇÕES E NOTAÇÕES BÁSICAS

[00121] Chaves, Usuários e Proprietários A não ser que especificado de outro modo, cada chave pública (“chave” para abreviação) é a longo prazo e relativo a um esquema de assinatura digital com a propriedade de exclusividade. Uma chave pública i ingressa no sistema quando outra chave pública j já no sistema realiza um pagamento para i.

[00122] Para cor, personifica-se chaves. Refere-se a uma chave i no masculino, diz que i é honesto, que i envia e recebe mensagens, etc. Usuário é um sinônimo para chave. Quando se deseja distinguir uma chave da pessoa a quem a mesma pertence, usa-se, respectivamente, os termos “chave digital” e ''proprietário''.

[00123] Sistemas Sem Permissão e Com Permissão. Um sistema é sem permissão, se uma chave digital estiver livre para integração a qualquer momento e um proprietário pode possuir múltiplas chaves digitais; e é com permissão de outro modo.

[00124] Representação Exclusiva Cada objeto em Algorand tem uma representação exclusiva. Em particular, cada conjunto é ordenado de uma maneira pré-especificada: por exemplo, primeiro lexicograficamente em x, então, em y, etc.

[00125] Relógios de Mesma Velocidade Não há um relógio global: em vez disso, cada usuário tem seu próprio relógio. Os relógios do usuário não precisam estar sincronizados de qualquer forma. Assume-se, entretanto, que todos têm a mesma velocidade.

[00126] Por exemplo, quando são 12pm de acordo com o relógio de um usuário i, podem ser 2:30pm de acordo com o relógio de outro usuário j, mas quanto forem 12:01 de acordo com o relógio de i, serão 2:31 de acordo com o relógio de j. Ou seja, “um minuto é igual (suficiente, essencialmente igual) para cada usuário”.

[00127] Rodadas Algorand é organizado em unidades lógicas, r — 0, 1, . . ., chamadas rodadas.

[00128] São consistentemente usados sobrescritos para indicar as rodadas. Para indicar que uma quantidade não numérica Q (por exemplo, uma série, uma chave pública, um conjunto, uma assinatura digital,

etc.) denomina uma rodada r, simplesmente se escreve Qr. Apenas quando Q é um número genuíno (em oposição a uma série binária interpretável como um número), escreve-se Q(r), de modo que o símbolo r não possa ser interpretado como o exponente de Q.

[00129] Em uma (no início de uma) rodada r > 0, o conjunto de todas as chaves públicas é , e o estado do sistema é

[00130] em que é a quantidade de dinheiro disponível para a chave pública i. Observa-se que é deduzível de Sr, e que Sr pode também especificar outros componentes para cada pública i.

[00131] Para a rodada 0, PK0 é o conjunto de chaves públicas iniciais, e S0 é o estado inicial. Assume-se que tanto PK0 quando S0 são de conhecimento comum no sistema. Por uma questão de simplicidade, no início da rodada r, também são PK1, . . . , PKr e S1, .. . , Sr.

[00132] Em uma rodada r, o estado do sistema transita de Sr para Sr+1: simbolicamente, Rodada r: Sr → Sr+1.

[00133] Pagamentos Em Algorand, os usuários realizam continuamente pagamentos (e disseminam os mesmos da forma descrita na subseção 2.7). Um pagamento de um usuário i ∈ PKr tem o mesmo formato e semântica que no Sistema Ideal. A saber,

[00134] O pagamento é individualmente válido em uma rodada r (é um pagamento de rodada r, para abreviação), se (1), sua quantidade a é menor ou igual a e (2) a mesma não aparece em qualquer conjunto de pagamentos oficial PAYr' para r' < r. (Conforme explicado abaixo,

a segunda condição significa que não foi ainda efetivado.

[00135] Um conjunto de pagamentos de rodada r de i é coletivamente válido se a soma de suas quantidades for no máximo .

[00136] Conjuntos de Pagamentos Um conjunto de pagamentos de rodada r P é um conjunto de pagamentos de rodada r de modo que, para cada usuário i, os pagamentos de i em P (possivelmente nenhum) sejam coletivamente válidos. O conjunto de todos os conjuntos de pagamentos de rodada r é . Um conjunto de pagamentos de rodada r P é máximo se nenhum superconjunto de P for um conjunto de pagamentos de rodada r.

[00137] Sugere-se na verdade que um pagamento também especifique uma rodada e não pode ser válido em qualquer rodada externa [ρ, ρ + k] , para algum número inteiro não negativo fixo k.4

[00138] Conjuntos de Pagamentos Oficiais Para cada rodada r, Algorand seleciona publicamente (de uma maneira descrita posteriormente) um único (possivelmente vazio) conjunto de pagamentos, PAYr, o conjunto de pagamentos oficial da rodada. (Essencialmente, PAYr representa os pagamentos de rodada r que aconteceram “realmente”.)

[00139] Como no Sistema Ideal (e Bitcoin), (1) a única forma de um novo usuário j entrar no sistema é ser o recebedor de um pagamento que pertencem ao conjunto de pagamentos oficinal PAYr de uma dada rodada r; e (2) PAYr determina o estado da rodada seguinte, Sr+1, a partir daquele da rodada atual, Sr. Simbolicamente, PAYr : Sr → Sr+1.

Isso simplifica a verificação de se ρ se tornou "efetivo" (isto é, simplifica a 4 determinação de se algum conjunto de pagamentos PAY r contém . Quando k = 0, se e, então, i precisa reapresentar ρ.

[00140] Especificamente,

[00141] 1. o conjunto de chaves públicas da rodada r + 1, PKr+1, consiste na união de PKr e o conjunto de todas as chaves de beneficiário que aparecem, pela primeira vez, nos pagamentos de PAYr; e

[00142] 2. a quantidade de dinheiro que um usuário i possui na rodada r + 1 é a soma de ai(r) — isto é, a quantidade de dinheiro i possuída na rodada anterior (0 se i ∉ PKr) — e a soma das quantidades pagas a i de acordo com os pagamentos de PAYr.

[00143] Em suma, como no Sistema Ideal, cada estado Sr+1 é deduzível a partir do histórico de pagamentos anteriores:

2.4 BLOCOS E BLOCOS COMPROVADOS

[00144] Em Algorand0, o bloco Br correspondente a uma rodada r especifica: o próprio r; o conjunto de pagamentos da rodada r, PAYr; uma quantidade a ser explicada, e o hash do bloco anterior, H(Br- 1 ). Assim, iniciando-se a partir de algum bloco fixo B0, tem-se um blockchain tradicional:

[00145] Em Algorand, a autenticidade de um bloco é realmente comprovada por informação separada, um “certificado de bloco” CERTr, que torna Br um bloco comprovado, . O Registro Mágico, portanto, é implantado pela sequência dos blocos comprovados,

[00146] Discussão Conforme pode ser visto, CERTr consiste em um conjunto de assinaturas digitais para H(Br), aqueles de uma maior parte dos membros de SVr, juntamente com uma prova de que cada um desses membros de fato pertence a SVr. Pode-se, obviamente, incluir os certificados CERT nos próprios blocos, mas é conceitualmente mais limpo mantê-los separado.)

[00147] Em Bitcoin, cada bloco precisa satisfazer uma propriedade especial, ou seja, precisa “conter uma solução de um quebra- cabeças criptográfico”, que torna a geração de bloco computacionalmente intensiva e bifurcações tanto inevitáveis quanto não raras. Em contrapartida, o blockchain de Algorand tem duas vantagens principais: é gerado com computação mínima e não bifurcará com probabilidade esmagadoramente alta. Cada bloco Bi é seguramente final assim que entra no blockchain.

2.5 PROBABILIDADE DE FALHA ACEITÁVEL

[00148] Para analisar a segurança de Algorand, é especificada a probabilidade, F, aceitável de que algo dê errado (por exemplo, que um conjunto de verificadores SV não tenha uma maioria honesta). Como no caso do comprimento de saída da função de hash criptográfico H, também F é um parâmetro. Mas, como nesse caso, é útil definir F como um valor concreto, de modo a obter uma compreensão mais intuitiva do fato de que é, de fato, possível, em Algorand, obter eficiência simultaneamente segurança suficiente e eficiência suficiente. Para enfatizar que F é o parâmetro que pode ser definido conforme desejado, na primeira e na segunda modalidades, definiu-se, respectivamente, F = 10-12 e = 10-18.

[00149] Discussão Observa-se que 10-12 é realmente menor que um em um trilhão, e acredita-se que tal escolha de F seja adequada na presente aplicação. Enfatiza-se que 10-12 não é a probabilidade com a qual o adversário pode forjar os pagamentos de um usuário honesto. Todos os pagamentos são sinalizados digitalmente e, assim, se as assinaturas digitais adequadas forem usadas, a probabilidade de forjar um pagamento está muito abaixo de 10-12 e é, de fato, essencialmente 0. O evento ruim que se pode tolerar com probabilidade F é que o blockchain de Algorand bifurque.

Observa-se que, com o presente ambiente de F e rodadas de um minuto de duração, espera-se que uma bifurcação ocorra em blockchain de Algorand tão raramente quanto (aproximadamente) uma vez em 1,9 milhão de anos. Em contrapartida, em Bitcoin, uma bifurcação ocorre bastante frequentemente.

[00150] Uma pessoa mais exigente pode definir F em um valor mais baixo. Para esse fim, na segunda modalidade, considera-se definir F em 10-18. Observa-se que, assumindo-se que um bloco é gerado a cada segundo, 1018 é o número estimado de segundos transcorridos pelo Universo até então: do Big Bang até o presente momento. Assim, com F = 10 -18, se um bloco for gerado em um segundo, seria esperado pela idade do Universo ver uma bifurcação.

2.6 O MODELO ADVERSO

[00151] Algorand é projetado para ser seguro em um modelo muito adverso. Explica-se.

[00152] Usuários Honestos e Maliciosos Um usuário é honesto se seguir suas instruções de protocolo e for perfeitamente capaz de enviar e receber mensagens. Um usuário é malicioso (isto é, Bizantino, na linguagem de computação distribuída) se desviar arbitrariamente de suas instruções prescritas.

[00153] O Adversário O Adversário é um algoritmo eficiente (tecnicamente tempo polinomial), personificado por cor, que pode imediatamente tornar malicioso qualquer usuário que desejar, em qualquer momento que desejar (submetido apenas a um limite superior ao número de usuários que pode corromper).

[00154] O adversário controla totalmente e coordena perfeitamente todos os usuários maliciosos. Ele atua em seu benefício, incluindo receber e enviar todas suas mensagens e pode deixar que desviem de suas instruções prescritas de formas arbitrárias. Ou pode simplesmente isolar um usuário corrompido enviando e recebendo mensagens. Esclarece- se que ninguém mais automaticamente tem conhecimento de que um usuário i é malicioso, embora a malícia de i possa transparecer pelas ações que o adversário faz com que tome.

[00155] Esse adversário forte, entretanto,

[00156] • Não tem potência computacional ilimitada e não pode forjar com sucesso a assinatura digital de um usuário honesto, exceto com probabilidade desprezível; e

[00157] • Não pode interferir de qualquer forma nas trocas de mensagem entre usuários honestos.

[00158] Além disso, sua habilidade de atacar usuários honestos é limitada por uma das seguintes suposições.

[00159] Maioria Honesta de Dinheiro Considera-se um contínuo de suposições de Maioria Honesta de Dinheiro (HMM): a saber, para cada número inteiro não negativo k e h real > 1/2,

[00160] HHMk > h: os usuários honestos em cada rodada r possuíam uma fração maior que h de todo dinheiro, no sistema na rodada r — k.

[00161] Discussão. Assumir que todos os usuários maliciosos coordenam perfeitamente suas ações (como se controladas por uma única entidade, o adversário) é uma hipótese bastante pessimista. A coordenação perfeita dentre muitos indivíduos é difícil de atingir. Talvez a coordenação apenas ocorra dentro de grupos separados de jogadores maliciosos. Mas, visto que não se pode ter certeza sobre o nível de coordenação que os usuários maliciosos podem possuir, é melhor a prevenção.

[00162] Assumir que o adversário pode corromper de modo secreto, dinâmico e imediato usuários é também pessimista. Afinal, realisticamente, obter controle completo das operações de um usuário poderia levar algum tempo.

[00163] A suposição de HMMk > h implica, por exemplo, que, se uma rodada (em média) for implantada em um minuto, então, a maior parte do dinheiro em uma dada rodada permanecerá em mãos honestas por pelo menos duas horas, se k = 120, e pelo menos uma semana, se k =

10.000.

[00164] Observa-se que as suposições de HMM e as suposições de Maioria Honesta de Potência de Computação anteriores estão relacionadas no sentido de que, visto que a potência de computação pode ser comprada com dinheiro, se usuários maliciosos possuírem a maior parte do dinheiro, então, os mesmos podem obter a maior parte da potência de computação.

2.7 O MODELO DE COMUNICAÇÃO

[00165] Prevê-se que a propagação de mensagens — isto é, “transmissão par a par”5 — seja o único meio de comunicação e assume-se que cada mensagem propagada atinja quase todos os usuários honestos de uma forma oportuna. Assume-se essencialmente que cada mensagem m propagada por um usuário honesto atinja, dentro de uma dada quantidade de tempo que depende do comprimento de m, todos os usuários honestos. (É realmente suficiente que m atinja uma porcentagem suficientemente alta dos usuários honestos.) 3 O PROTOCOLO BA* EM UM AMBIENTE TRADICIONAL

[00166] Conforme já enfatizado, o acordo bizantino é um ingrediente chave de Algorand. De fato, é através do uso de tal protocolo BA que Algorand não é afetado por bifurcações. Entretanto, para estar seguro contra o adversário forte, Algorand precisa se basear em um protocolo BA 5 Essencialmente, como em Bitcoin, quando um usuário propaga uma mensagem m, cada usuário ativo i que recebe m pela primeira vez, seleciona de modo aleatório e independente um número adequadamente pequeno de usuários ativos, seus "vizinhos", a quem encaminha m, possivelmente até receber um reconhecimento dos mesmos. A propagação de m termina quando nenhum usuário recebe m pela primeira vez.

que satisfaz a nova restrição de substituibilidade do jogador. Adicionalmente, para Algorand ser eficiente, tal protocolo BA precisa ser muito eficiente.

[00167] Os protocolos BA foram primeiramente definidos para um modelo de comunicação idealizado, redes completas sincronizadas (redes SC). Tal modelo permite um projeto mais simples e análise de protocolos BA. Consequentemente, nessa seção, é introduzido um novo protocolo BA, BA*, para redes SC e ignorando o problema de substituibilidade do jogador totalmente. O protocolo BA* é uma contribuição de valor separado. De fato, esse é o protocolo BA criptográfico mais eficiente para redes SC conhecidas até o momento.

[00168] Para usar o mesmo dentro do presente protocolo Algorand, modificou-se BA* um pouco, de modo a representar os presentes modelo e contexto de comunicação diferentes.

[00169] Começa-se recordando o modelo em que BA* opera e a noção de acordo bizantino.

3.1 REDES COMPLETAS SINCRONIZADAS E

ADVERSÁRIOS CORRELACIONADOS

[00170] Em uma rede SC, há um relógio comum, marcando a cada momento integral r = 1, 2, . . .

[00171] Em cada clique de tempo par r, cada jogador i envia instantânea e simultaneamente uma única mensagem (possivelmente a mensagem vazia) a cada jogador j, incluindo ele mesmo. Cada é corretamente recebido no clique de tempo r + 1 pelo jogador j, juntamente com a identidade do emissor i.

[00172] Novamente, em um protocolo de comunicação, um jogador é honesto se seguir suas instruções prescritas e malicioso de outro modo. Todos os jogadores maliciosos são totalmente controlados e perfeitamente coordenados pelo adversário, que, em particular, recebe imediatamente todas as mensagens endereçadas a jogadores maliciosos e escolhem as mensagens que enviam.

[00173] O adversário pode tornar imediatamente malicioso qualquer usuário honesto que queira em qualquer clique de tempo ímpar que quiser, submetido apenas a um limite superior possível t ao número de jogadores maliciosos. Ou seja, o adversário “não pode interferir nas mensagens já enviadas por um usuário honesto i”, que serão enviadas normalmente.

[00174] O adversário também tem a capacidade adicional de ver instantaneamente, em cada rodada par, as mensagens que os jogadores atualmente honestos enviam, e usar instantaneamente essas informações para escolher as mensagens que jogadores maliciosos enviar na mesma marcação de tempo.

3.2 A NOÇÃO DE UM ACORDO BIZANTINO

[00175] A noção de acordo bizantino pode ter sido primeiramente introduzida para o caso binário, ou seja, quando cada valor inicial consiste em um bit. Entretanto, o mesmo foi rapidamente estendido a valores iniciais arbitrários. Um protocolo BA significa um de valor arbitrário.

[00176] Definição 3.1. Em uma rede sincronizada, P é um protocolo de n jogadores, cujo conjunto de jogadores é de conhecimento comum entre os jogadores, t um número inteiro positivo, de modo que n ≥ 2t + 1. Diz-se que P é um protocolo de acordo bizantino (n, t) de valor arbitrário (respectivamente, binário) com solidez σ ∈ (0, 1) se, para cada conjunto de valores, V não contiver o símbolo especial (respectivamente, para V = {0, 1} ), em uma execução em que no máximo t dos jogadores são maliciosos e em que cada jogador i começa com um valor inicial vi ∈ V, cada jogador honesto j para com probabilidade 1 de emitir um valor outi de modo a satisfazer, com probabilidade pelo menos σ, as seguintes duas condições:

[00177] 1. Acordo: Existe saída de modo que a outi = out para todos os jogadores honestos i.

[00178] 2. Consistência: se, para algum valor para todos os jogadores i, então out = v.

[00179] Denomina-se saída como a saída de P, e a cada outi como saída do jogador i.

3.3 A NOTAÇÃO DE BA #

[00180] Nos presentes protocolos BA, um jogador é necessário para contar quantos jogadores enviam uma dada mensagem em uma dada etapa. Consequentemente, para cada valor possível v que pode ser enviado,

[00181] (ou apenas #i(v) quando s está claro) é o número de jogadores j de cada i que recebeu v na etapa s.

[00182] Recordando que um jogador i recebe exatamente uma mensagem de cada jogador j, se o número de jogadores é n, então, para todos i e s,

3.4 O NOVO PROTOCOLO BINÁRIO BA BBA*

[00183] Nessa seção, apresenta-se um novo protocolo binário BA, BBA*, que se baseia na honestidade de mais de dois terços dos jogadores e é muito rápido: não importando o que os jogadores maliciosos possam fazer, cada execução desse circuito principal não é apenas trivialmente executado, mas coloca os jogadores em acordo com probabilidade 1/3.

[00184] Em BBA*, cada jogador tem sua própria chave pública de um esquema de assinatura digital que satisfaça a propriedade de assinatura exclusiva. Visto que esse protocolo se destina a ser executado em rede completa sincronizada, não há necessidade de um jogador i sinalizar cada uma de suas mensagens.

[00185] As assinaturas digitais são usadas para gerar um bit aleatório suficientemente comum na etapa 3. (Em Algorand, as assinaturas digitais são usadas para autenticar todas as outras mensagens também.)

[00186] O protocolo exige uma configuração mínima: uma série aleatória comum r; independente das chaves dos jogadores. (Em Algorand, r é na realidade substituído pela quantidade Qr.)

[00187] O protocolo BBA* é um circuito em 3 etapas, em que os jogadores trocam repetidamente valores booleanos, e diferentes jogadores podem sair desse circuito em tempos diferentes. Um jogador i sai desse circuito por propagação, em alguma etapa, de um valor especial 0* ou um valor especial 1*, instruindo-se, assim, todos os jogadores a “simular” que, respectivamente, receberam 0 e 1 de i em todas as etapas futuras. (Alternativamente: assume-se que a última mensagem recebida por um jogador j de outro jogador i foi um bit b. Então, em qualquer etapa em que não recebe qualquer mensagem de i, j atua como se i tivesse enviado o bit b.)

[00188] O protocolo usa um contador que representa quantas vezes seu circuito em 3 etapas foi executado. No início da BBA*, (Pode pensar em γ como um contador global, mas é na realidade aumentado por cada jogador individual a cada momento que o circuito é executado.)

[00189] Há n ≥ 3t + 1, em que t é o número máximo possível de jogadores maliciosos. Uma série binária x é identificada com o número inteiro cuja representação binária (com lideranças possíveis 0s) é x; e lsb(x) denota o bit menos significativo de x. PROTOCOLO BBA*

[00190] (COMUNICAÇÃO) ETAPA 1. [Etapa Moeda Fixa em 0] Cada jogador i envia bi.

1.1 Se então i define bi = 0, envia 0*, emite outi = 0 e HALTS.

1.2 Se então, i define bi = 1.

1.3 De outro modo, i define bi = 0.

[00191] (COMUNICAÇÃO) ETAPA 2. [Etapa Moeda Fixa em 1] Cada jogador i envia bi.

2.1 Se então, i define bi = 1, envia 1*m emite outi =1, e HALTS.

2.2 Se então, i define bi = 0.

2.3 De outro modo, i define bi = 1.

[00192] (COMUNICAÇÃO) ETAPA 3. [Etapa Moeda Genuinamente Lançada] Cada jogador i envia bi e

3.1 Se então, i define bi = 0.

3.2 Se então, i define bi = 1.

3.3 De outro modo, sendo Si = {j ϵ N, que envia a i uma mensagem adequada nessa etapa 3}, i define aumenta em 1; e retorna à Etapa 1.

[00193] Teorema 3.1. Sempre que n ≥ 3t + 1, BBA* é um protocolo binário (n,t)-BA com solidez 1.

[00194] Um prova do Teorema 3.1 pode ser encontrada em https://people.csail.mit.edu/silvio/ Selected- ScientificPapers/DistributedComputation/BYZANTINEAGREEMENTMADET RIVIAL.15 pdf.

3.5 CONSENSO CLASSIFICADO E O PROTOCOLO GC

[00195] Recorda-se, para valores arbitrários, uma noção de consenso muito mais fraca que acordo bizantino.

[00196] Definição 3.2. P é um protocolo em que o conjunto de todos os jogadores é de conhecimento comum, e cada jogador i privadamente conhece um valor inicial arbitrário

[00197] Diz-se que P é um protocolo de consenso classificado por (n, t) se, em cada execução com n jogadores, no máximo t dos quais são maliciosos, cada jogador honesto i para de emitir um par valor-classe (vi, gi), em que gi ∈ {0, 1, 2}, de modo a satisfazer as seguinte três condições:

1. Para todos os jogadores honestos i e j,

2. Para todos os jogadores honestos i e j,

3. Se para algum valor v, então, e para todos os jogadores honestos i.

[00198] O protocolo em duas etapas a seguir GC é um protocolo de consenso classificado na literatura. Para corresponder às etapas do protocolo da seção 4.1, as etapas foram nomeadas, respectivamente 2 e 3, de GC. (De fato, a primeira etapa de Algorand’1 refere- se a outra coisa: a saber, propor um novo bloco.)

PROTOCOLO GC

[00199] ETAPA 2. Cada jogador i envia a todos os jogadores.

[00200] ETAPA 3. Cada jogador i envia a todos os jogadores a série x se e apenas se

[00201] DETERMINAÇÃO DE SAÍDA. Cada jogador i emite o par (vi, gi) computado conforme segue: • Se, para algum x, então, e . • Se, para algum x, então, e • De outro modo, e

[00202] Visto que o protocolo GC é um protocolo na literatura, sabe-se que o teorema a seguir se mantém.

[00203] Teorema 3.2. Se então GC é um protocolo de difusão classificado por (n, t).

3.6 O PROTOCOLO BA*

[00204] Será descrito agora o protocolo de BA de valor arbitrário BA* por meio do protocolo de BA binário BBA* e do protocolo de consenso classificado GC. Abaixo, o valor inicial de cada jogador i é PROTOCOLO BA*

[00205] ETAPAS 1 E 2. Cada jogador i executa GC, na entrada de modo a computar um par (vi,gi).

[00206] ETAPA 3, . . . Cada jogador i executa BBA* — com entrada inicial 0, se gi = 2, e 1 de outro modo — de modo a computar a saídai de bit.

[00207] DETERMINAÇÃO DE SAÍDA. Cada jogador i emite vi, se a saídai = 0, e de outro modo.

[00208] Teorema 3.3. Sempre que n ≥ 3t + 1, BA* é um protocolo (n, t)-BA com solidez 1.

[00209] Prova. Foi primeiramente provada a Consistência e, então, o Acordo.

[00210] PROVA DE CONSISTÊNCIA. Supõe-se que, para algum valor, v . Então, pela propriedade 3 do consenso classificado, após a execução de GC, todos os jogadores honestos emitem (v,2). Consequentemente, 0 é o bit inicial de todos os jogadores honestos no final da execução do BBA*. Assim, pela propriedade de Acordo do acordo Bizantino binário, no final da execução do BA*, outi = 0 para todos os jogadores honestos. Isso implica que a saída de cada jogador honesto i no

BA* é vi = v.

[00211] PROVA DE ACORDO. Já que BBA* é um protocolo de BA binário, ou

[00212] (A) outi = 1 para todo jogador honesto i, ou

[00213] (B) outi = 0 para todo jogador honesto i.

[00214] No caso A, todos os jogadores honestos emitem no BA*, e, assim, o Acordo se mantém. Considere agora o caso B. Nesse caso, na execução do BBA*, o bit inicial de pelo menos um jogador honesto i é 0. (De fato, se o bit inicial de todos os jogadores honestos for 1, então, pela propriedade de Consistência do BBA*, ter-se-ia outj = 1 para todo j honesto.) Consequentemente, após a execução de GC, i emite o par (v, 2) para algum valor v. Assim, pela propriedade 1 do consenso classificado, gj > 0 para todos os jogadores honestos j. Consequentemente, pela propriedade 2 do consenso classificado, vj = v para todos os jogadores honestos j. Isso implica que, no final do BA*, cada jogador honesto j emite v.

Assim, o Acordo se mantém também no caso B.

[00215] Já que tanto a Consistência quanto o Acordo se mantêm, BA* é um protocolo de BA de valor arbitrário. ■

[00216] O Protocolo BA* funciona também em redes de transmissão e, de fato, satisfaz a jogador capacidade de substituição que é crucial para Algorand seja seguro no modelo bastante contraditório previsto.

[00217] A Capacidade de Substituição do Jogador do BBA* e BA* permite agora o fornecimento de alguma intuição do motivo de os protocolos BA* e BBA* poderem ser adaptados para serem executados em uma rede em que a comunicação é por meio de transmissão de ponto a ponto, satisfazendo a capacidade de substituição do jogador. Para concretude, supõe-se que a rede tem 10M de usuários e que cada etapa x do BBA* (ou BA*) é executada por um comitê de 10.000 jogadores, que foram aleatoriamente selecionados por meio de sorteio criptográfico secreto e têm, assim, credenciais provando serem qualificados para enviar mensagens na etapa x. Supõe-se que cada mensagem enviada em uma determinada etapa especifica o número de etapa, é digitalmente assinada por seu remetente e inclui a credencial provando que seu remetente é qualificado para falar nessa etapa.

[00218] Primeiramente, se a porcentagem h de jogadores honestos for suficientemente maior do que 2/3 (por exemplo, 75%), então, com grande probabilidade, o comitê selecionado em cada etapa tem a maioria honesta de 2/3 exigida.

[00219] Adicionalmente, o fato de que o comitê aleatoriamente selecionado forte de 10.000 muda em cada etapa não impede o funcionamento correto do BBA* ou BA*. De fato, em cada protocolo, um jogador i na etapa s reage apenas à multiplicidade com a qual, na etapa s — 1, ele recebeu uma determinada mensagem m. Já que se está em uma rede de transmissão, todas as mensagens enviadas na etapa s — 1 alcançarão (imediatamente, para o propósito dessa intuição) todos os usuários, incluindo aqueles selecionados para jogar na etapa s. Ademais, devido ao fato de que todas as mensagens enviadas na etapa s — 1 especificam o número de etapa e incluem a credencial de que o remetente era, de fato, autorizado a falar na etapa s — 1. Consequentemente, se ele tiver sido selecionado também na etapa s — 1 ou não, um usuário i selecionado para jogar na etapa s é perfeitamente capaz de contar corretamente a multiplicidade com a qual ele recebeu uma mensagem da etapa s — 1 correta. Não importa, de modo algum, se ele estava jogando em todas as etapas até o momento ou não. Todos os usuários estão “no mesmo barco” e, assim, podem ser substituídos facilmente por outros usuários. 4 DUAS MODALIDADES DE ALGORAND

[00220] Conforme discutido, em um nível muito alto, uma rodada de Algorand procede idealmente conforme segue. Primeiro, um usuário aleatoriamente selecionado, o líder, propõe e circula um novo bloco. (Esse processo inclui selecionar inicialmente alguns líderes potenciais e, então, garantir que, pelo menos uma boa fração do tempo, um único líder comum emerja). Segundo, um comitê aleatoriamente selecionado de usuários é selecionado e alcança o acordo Bizantino no bloco proposto pelo líder. (Esse processo inclui que cada etapa do protocolo de BA é executada por um comitê separadamente selecionado). O bloco acordado é, então, digitalmente assinado por um determinado limite (TH) dos membros do comitê. Essas assinaturas digitais são propagadas de modo que todos tenham certeza de qual é o novo bloco. (Isso inclui circular a credencial dos assinantes e autenticar apenas o hash do novo bloco, assegurando que todos tenham a garantia de aprender o bloco, uma vez que o hash é tornado claro).

[00221] Nas duas seções seguintes, são apresentadas duas modalidades do projeto de Algorand básico, e que funcionam respectivamente sob uma suposição de maioria de usuários honestos apropriada. Na Seção ??, mostra-se como adotar essas modalidades para funcionarem sob uma suposição de maioria honesta de dinheiro.

[00222] prevê apenas que > 2/3 dos membros do comitê são honestos. Adicionalmente, em , o número de etapas para alcançar o acordo Bizantino é limitado por um número adequadamente alto, de modo que seja garantido que o acordo seja alcançado com grande probabilidade dentro de um número fixo de etapas (mas exigindo potencialmente tempo mais longo do que as etapas de No caso remoto em que o acordo não é ainda alcançado na última etapa, o comitê concorda com o bloco vazio, que é sempre válido.

[00223] Prevê que o número de membros honestos em um comitê é sempre maior ou igual a um limite fixo tH (que garante que, com grande probabilidade, pelo menos 2/3 dos membros do comitê são honestos). Adicionalmente, permite que o acordo Bizantino seja alcançado em um número arbitrário de etapas (mas potencialmente em um tempo mais curto do que

[00224] Aqueles versados na técnica entenderão que muitas variantes dessas modalidades básicas podem ser derivadas. Em particular, é fácil, dado Algorand'2, modificar de modo a permitir alcançar o acordo Bizantino em um número arbitrário de etapas.

[00225] Ambas as modalidades compartilham o seguinte núcleo comum, notações, noções e parâmetros.

4.1 UM NÚCLEO COMUM

[00226] Objetivos Idealmente, para cada rodada r, Algorand deve satisfazer as seguintes propriedades:

[00227] 1. Exatidão Perfeita. Todos os usuários honestos concordam com o mesmo bloco Br.

[00228] 2. Completeza 1 Com probabilidade 1, o bloco Br foi escolhido por um usuário honesto.

[00229] (De fato, um usuário malicioso pode sempre escolher um bloco cujo conjunto de pagamentos contém os pagamentos apenas de seus “amigos”).

[00230] Certamente, garantir a exatidão perfeita sozinha é trivial: todos sempre escolhem o conjunto de pagamentos oficial PAYr para ser vazio. Mas, nesse caso, o sistema teria completeza 0. Infelizmente, garantir tanto a exatidão perfeita quanto a completeza 1 não é fácil na presença de usuários maliciosos. Algorand adota, assim, um objetivo mais realista. Informalmente, deixando h denotar a porcentagem de usuários que são honestos, h > 2/3, o objetivo de Algorand é

[00231] Garantindo, com grande probabilidade, exatidão perfeita e completeza próximas a h.

[00232] Privilegiar a exatidão em vez da completeza parece ser uma escolha razoável: os pagamentos não processados em uma rodada podem ser processados no próximo, mas deve-se evitar bifurcações, se possível.

[00233] Acordo Bizantino Conduzido Desconsiderando o tempo e comunicação excessivos por um momento, a Exatidão perfeita poderia ser garantida conforme segue. No início da rodada r, cada usuário i propõe seu próprio bloco candidato . Então, todos os usuários alcançam o acordo Bizantino em apenas um dos blocos candidatos. De acordo com a introdução, o protocolo de BA empregado exigem uma maioria honesta de 2/3 e é passível de substituição de jogador. Cada uma de suas etapas pode ser executada por um pequeno conjunto aleatoriamente selecionado de verificadores, que não compartilham quaisquer variáveis internas.

[00234] Infelizmente, essa abordagem não funciona bem. Isto é, devido ao fato de que os blocos candidatos propostos pelos usuários honestos são, mais provavelmente, totalmente diferentes um do outro. De fato, cada usuário honesto vê pagamentos diferentes. Assim, embora os conjuntos de pagamentos vistos por diferentes usuários honestos possam ter muitas sobreposições, é improvável que todos os usuários honestos construam de propósito o mesmo bloco. Consequentemente, o acordo de consistência do protocolo de BA nunca é vinculado, apenas o acordo um é, e, assim, o acordo pode sempre ser alcançado em em vez de em um bom bloco.

[00235] evita esse problema conforme segue. Primeiro, um líder para a rodada é selecionado. Então, propaga seu próprio bloco candidato, Finalmente, os usuários alcançam acordo sobre o bloco que eles realmente recebem de Devido ao fato de que, sempre que é honesto, tanto a Exatidão Perfeita quanto a Completeza 1 se mantêm, garante que seja honesto com probabilidade próxima a h.

[00236] Seleção de Líder Em Algorand, o r-ésimo bloco é da forma

[00237] Conforme já mencionado na introdução, a quantidade Qr-1 é cuidadosamente construída de modo a ser essencialmente não manipulável pelo adversário bastante forte. (Posteriormente nessa seção, será fornecida alguma intuição sobre o motivo de isso ser o caso). No início de uma rodada r, todos os usuários conhecem o blockchain até o momento, B0, . . . , Br-1, a partir da qual eles deduzem o conjunto de usuários de cada rodada anterior: isto é, . Um líder potencial da rodada r é um usuário i de modo que

[00238] Explica-se. Note que, já que a quantidade Qr-1 é deduzível a partir do bloco Br-1, por causa da propriedade de recuperabilidade de mensagem do esquema de assinatura digital subjacente. Ademais, o esquema de assinatura subjacente satisfaz a propriedade de exclusividade.

Assim, é uma cadeia binária exclusivamente associada a i e r.

Consequentemente, já que H é um oráculo aleatório, é uma cadeia de 256 bits de comprimento aleatória exclusivamente associada a i e r. O símbolo “.” na frente de é o ponto decimal (no caso, binário), de modo que seja a expansão binária de um número de 256 bits aleatório entre 0 e 1 exclusivamente associado a i e r. Assim, a probabilidade de que ri seja menor ou igual a p é, essencialmente,

p.

[00239] A probabilidade p é escolhida de modo que, com grande (isto é, 1 — F) probabilidade, pelo menos um verificador potencial seja honesto. (De fato, p é escolhido para ser a menor tal probabilidade). Note que, já que i é o único com a capacidade para computar suas próprias assinaturas, ele sozinho pode determinar se ele é um verificador potencial da rodada 1. Entretanto, revelando sua própria credencial ,i pode provar para qualquer um que é um verificador potencial da rodada r.

[00240] O líder é definido como sendo o líder potencial cuja credencial verificada por hash é menor do que a credencial verificada por hash de outro líder potencial j: isto é,

[00241] Note que, já que um malicioso pode não revelar sua credencial, o líder correto da rodada r pode nunca ser conhecido, e que, impedindo vínculos improváveis, é, de fato, o único líder da rodada r.

[00242] É finalmente apresentado um último, mas importante, detalhe: um usuário i pode ser um líder potencial (e, assim, o líder) de uma rodada r apenas se ele pertencer ao sistema por pelo menos k rodadas. Isso garante a não manipulabilidade de Qr e todas as futuras quantidades Q. De fato, um dos líderes potenciais realmente determinarão Qr.

[00243] Seleção de Verificador Cada etapa s > 1 da rodada r é executada por um pequeno conjunto de verificadores, . Novamente, cada verificador é aleatoriamente selecionado dentre os usuários já no sistema k rodadas antes de r, e novamente por meio da quantidade especial Qr-1. Especificamente, é um verificador em se

[00244] Mais uma vez, apenas i sabe se ele pertence a SVr,s, mas, se esse for o caso, ele poderia provar isso exibindo sua credencial

. Um verificador i ∈ envia uma mensagem, na etapa s da rodada r, e essa mensagem inclui sua credencial de modo a permitir que os verificadores f na próxima etapa reconheçam que é uma mensagem da etapa s legítima.

[00245] A probabilidade p' é escolhida de modo a garantir que, em SVr,s, #bom seja o número de usuários honestos e #mau seja o número de usuários maliciosos, com grande probabilidade de que as duas condições a seguir se mantenham.

[00246] Para a modalidade

[00247] (1) #bom > 2 · #mau e

[00248] (2) #bom + 4 · #mau < 2n, em que n é a cardinalidade esperada de SVr,s.

[00249] Para a modalidade Algorand'2:

[00250] (1) #bom > tH e

[00251] (2) #bom + 2#mau < 2tH, em que tH é um limite especificado.

[00252] Essas condições implicam que, com probabilidade suficientemente alta, (a) na última etapa do protocolo de BA, haverá pelo menos um determinado número de jogadores honestos para assinar digitalmente o novo bloco Br, (b) apenas um bloco por rodada pode ter o número necessário de assinaturas, e (c) o protocolo de BA usado tem (em cada etapa) a maioria honesta de 2/3 exigida.

[00253] Geração de Bloco de Esclarecimento Se o líder da rodada r for honesto, então, o bloco correspondente está na forma

[00254] em que o conjunto de pagamentos PAYr é máximo, (lembrar que todos os conjuntos de pagamentos são, por definição,

coletivamente válidos).

[00255] De outro modo (isto é, se for malicioso), Br tem uma das duas seguintes formas possíveis:

[00256] Na primeira forma, é um conjunto de pagamentos (não necessariamente máximo) e pode ser e i é um líder potencial da rodada r. (Entretanto, i pode não ser o líder Isso pode de fato acontecer se mantiver secreta sua credencial e não se revelar).

[00257] A segunda forma surge quando, na execução da rodada r do protocolo de BA, todos os jogadores honestos emitirem o valor padrão, que é o bloco vazio neste pedido. (Por definição, as possíveis saídas de um protocolo de BA incluem um valor padrão, genericamente denotado por Consulte a seção 3.2.)

[00258] Note que, embora os conjuntos de pagamentos estejam vazios em ambos os casos, e são blocos sintaticamente diferentes e surgem em duas situações diferentes: respectivamente, “tudo ocorreu bem o suficiente na execução do protocolo de BA” e “algo deu errado no protocolo de BA, e o valor padrão foi emitido”.

[00259] Descreve-se agora intuitivamente como a geração do bloco Br procede na rodada r de Na primeira etapa, cada jogador elegível, isto é, cada jogador verifica se ele é um líder potencial. Se esse for o caso, então, solicita-se que i, com o uso de todos os pagamentos que ele viu até o momento, e o blockchain atual, prepare secretamente um conjunto de pagamentos máximo, e monte secretamente seu bloco candidato, Br = . Isto é, ele não apenas inclui em como seu segundo componente, o recém preparado conjunto de pagamentos, mas também, como seu terceiro componente, sua própria assinatura de Qr-1, o terceiro componente do último bloco, . Finalmente, ele propaga sua mensagem da etapa 1 da rodada r, que inclui (a) seu bloco candidato (b) sua assinatura apropriada de seu bloco candidato (isto é, sua assinatura do hash de e (c) sua própria credencial que prova que ele é, de fato, um verificador potencial da rodada r.

[00260] (Note que, até um i honesto produzir sua mensagem o Adversário não tem ideia de que i é um verificador potencial. Se ele desejar corromper líderes potenciais honestos, o Adversário pode também corromper jogadores honestos aleatórios. Entretanto, uma vez que ele vê já que o mesmo contém a credencial de i, o adversário sabe e poderia corromper i, mas não pode impedir o que é viralmente propagado de alcançar todos os usuários no sistema).

[00261] Na segunda etapa, cada verificador selecionado j ∈ tenta identificar o líder da rodada. Especificamente, j toma as credenciais da etapa 1 , contidas na mensagem da etapa 1 apropriada que ele recebeu; verifica por hash todas as mesmas, isto é, computa encontra o credencial , cujo hash é lexicograficamente mínimo; e considera como o líder da rodada .

[00262] Lembre-se que cada credencial considerada é uma assinatura digital de Qr-1, que é exclusivamente determinado por ie que H é o oráculo aleatório, e, assim, que cada é uma cadeia de 256 bits de comprimento aleatória exclusiva para cada líder potencial i da rodada r.

[00263] A partir disso, pode-se concluir que, se a própria cadeia de 256 bits Qr-1 for aleatória e independentemente selecionada, essas seriam as credenciais verificadas por hash de todos os líderes potenciais da rodada r. De fato, todos os líderes potenciais são bem definidas e, assim, também são suas credenciais (realmente computadas ou não). Ademais, o conjunto de líderes potenciais da rodada r é um subconjunto aleatório dos usuários da rodada r — k, e um líder potencial honesto i sempre constrói e propaga apropriadamente sua mensagem que contém a credencial de i. Assim, já que a porcentagem de usuários honestos é h, não importa o que os líderes potenciais maliciosos possam fazer (por exemplo, revelar ou ocultar suas próprias credenciais), a credencial do líder potencial verificada por hash mínima pertence a um usuário honesto, que é necessariamente identificado por todos como sendo o líder da rodada r. Consequentemente, se a própria cadeia de 256 bits Qr-1 for aleatória e independentemente selecionada, com probabilidade exatamente h (a) o líder é honesto e (b) para todos os verificadores da etapa 2 honestos j.

[00264] Na realidade, as credenciais verificadas por são, sim, aleatoriamente selecionadas, mas dependem de que não é aleatória e independentemente selecionado. Uma análise cuidadosa, entretanto, garante que é suficientemente não manipulável para garantir que o líder de uma rodada seja honesto com probabilidade suficientemente próxima a h: a saber,

[00265] Por exemplo, se h = 80%, então, 0,7424.

[00266] Tendo identificado o líder da rodada (o que eles fazem corretamente quando o líder é honesto), a tarefa dos verificadores da etapa 2 é iniciar a execução de BA* usando como valores iniciais o que eles acreditam ser o bloco do líder. Na realidade, a fim de minimizar a quantidade de comunicação exigida, um verificador j ∈ não usa, como sua entrada , o valor para o protocolo Bizantino, o bloco que ele realmente recebeu de (o usuário j acredita ser o líder), mas o líder, mas o hash desse bloco, isto é, . Assim, mediante a terminação do protocolo de BA, os verificadores da última etapa não computam o bloco Br da rodada r, mas computam (autenticam e propagam) H(Br). Consequentemente, já que H(Br) é digitalmente assinado por suficientemente muitos verificadores da última etapa do protocolo de BA, os usuários no sistema perceberão que H(Br) é o hash do novo bloco. Entretanto, eles devem também recuperar o (ou esperar pelo, já que a execução é bastante assíncrona) próprio bloco Br, o que o protocolo garante que esteja de fato disponível, não importa o que o adversário possa fazer.

[00267] Assincronia e Temporização e têm um grau significativo de assincronia. Isso é devido ao fato de que o adversário tem grande latitude na programação da entrega das mensagens sendo propagadas. Adicionalmente, se o número total de etapas em uma rodada for limitado ou não, há a contribuição da variância pelo número de etapas realmente tomadas.

[00268] Assim que ele aprende os certificados de B0, . . . , Br-1, um usuário i computa Qr-1 e começa a trabalhar na rodada r, verificando se ele é um líder potencial ou um verificador em alguma etapa s da rodada r.

[00269] Supondo que i deve atuar na etapa s, em luz da assincronia discutida, i depende de várias estratégias para garantir que ele tenha informações suficientes antes de ele agir.

[00270] Por exemplo, ele pode esperar receber pelo menos um determinado número de mensagens dos verificadores da etapa anterior (como em ou esperar por um tempo suficiente para garantir que ele receba as mensagens de suficientemente muitos verificadores da etapa anterior (como em

[00271] A Semente Qr e o Parâmetro de Retrospectiva k Lembre que, idealmente, as quantidades Qr devem ser aleatórias e independentes, embora baste que as mesmas sejam suficientemente não manipuláveis pelo adversário.

[00272] À primeira vista, poder-se-ia escolher Qr-1 para coincidir com H (PAYr-1). Uma análise elementar revela, entretanto, que usuários maliciosos podem se aproveitar desse mecanismo de seleção. 6 Algum esforço adicional mostra que inúmeras outras alternativas, com base nas quantidades de bloco tradicionais, são facilmente exploráveis pelo Encontra-se no início da rodada r — 1. Assim, Qr-2 = PAYr-2 é publicamente 6 conhecido, e o Adversário sabe privadamente quem são os líderes potenciais que ele controla. Supõe-se que o adversário controla 10% dos usuários, e que, com uma probabilidade bastante alta, um usuário malicioso w é o líder potencial da rodada r — 1. Isto é, supõe-se que H (SIGw (r — 2, 1, Qr-2)) é tão pequeno que é altamente improvável que um líder potencial honesto seja realmente o líder da rodada r — 1. (Lembre-se que, já que foram escolhidos líderes potenciais por meio de um mecanismo de sorteio criptográfico secreto, o Adversário não sabe quem são os líderes potenciais honestos). O adversário, portanto, está na posição invejável de escolher o conjunto de pagamentos PAY' que ele quer tornar o mesmo o conjunto de pagamentos oficial da rodada r - 1. Entretanto, ele pode fazer mais. Ele pode também garantir que, com alta probabilidade, (*) um de seus usuários maliciosos sejam o líder também da rodada r, de modo que ele possa selecionar livremente qual será o PAYr. (E assim por diante. Pelo menos por um longo tempo, isto é, enquanto esses eventos de alta probabilidade realmente ocorrem). Para garantir (*), o Adversário age conforme segue. Deixar que PAY' seja o conjunto de pagamentos que o Adversário prefere para a rodada r - 1. Então, ele computa H(PAY') e verifica se, para algum jogador já malicioso z, SIG z(r, 1, H(PAY')) é particularmente pequeno, isto é, pequeno o suficiente para que, com probabilidade bastante alta z, seja o líder da rodada r. Se esse for o caso, então, ele instrui w a escolher seu bloco candidato para ser . De outro modo, ele tem dois outros usuários maliciosos x e y para continuar gerando um novo pagamento um a partir do outro, até, para algum usuário malicioso z (ou até mesmo para algum usuário fixo z), ser particularmente pequeno também. Esse experimento parará bem rapidamente. E quando o mesmo para, o Adversário solicita que w proponha o bloco candidato

Adversário para garantir que líderes maliciosos sejam bastante frequentes. Em vez disso, define-se específica e indutivamente a nova quantidade Qr de modo a ter a capacidade de provar que a mesma é não manipulável pelo Adversário. A saber, se Br não for o bloco vazio, e de outro modo.

[00273] A intuição do motivo de essa construção de Qr funcionar é conforme segue. Suponha por um momento que Qr-1 é verdadeiramente aleatória e independentemente selecionado. Então, será também Qr? Quando é honesto, a resposta é (a grosso modo) sim. Isso é assim devido ao fato de que

[00274] é uma função aleatória. Quando é malicioso, entretanto, Qr não é mais univocamente definido a partir de Qr-1 e Há pelo menos dois valores separados para Qr. Um continua a ser e o outro é H(Qr-1,r). Primeiramente, argumenta-se que, embora a segunda escolha seja arbitrária de algum modo, uma segunda escolha é absolutamente mandatória. A razão para isso é que um malicioso pode sempre fazer com que blocos candidatos totalmente diferentes sejam recebidos pelos verificadores honestos da segunda etapa.7 Uma vez que isso for o caso, pode ser fácil garantir que o bloco ultimamente acordado por meio do BA da rodada r será o bloco padrão e, assim, não conterá a assinatura digital de ninguém de Qr-1. Mas o sistema deve continuar e, para isso, precisa de um líder para a rodada r. Se esse líder for automática e abertamente 7 Por exemplo, para manter isso simples (mas extremo), "quando o tempo da segunda etapa está quase expirando", poderia enviar diretamente por e-mail um bloco candidato diferente Bi a cada usuário i. Desse modo, quem quer que sejam os verificadores da etapa 2, eles receberão blocos totalmente diferentes.

selecionado, então, o Adversário o corromperá trivialmente. Se for selecionado pela Qr-1 anterior por meio do mesmo processo, então, será novamente o líder na rodada r + 1. Propõe-se especificamente usar o mesmo mecanismo de sorteio criptográfico secreto, mas aplicado a uma nova quantidade Q: a saber, H(Qr-1,r). Ter essa quantidade como a saída de H garante que a saída seja aleatória, e incluir r como a segunda entrada de H, enquanto todos os outros usos de H têm ou uma única entrada ou pelo menos três entrada, “garante” que tal Qr é independentemente selecionada. Novamente, a escolha específica de Qr alternativa não importa, o que importa é que tem duas escolhas para Qr, e, assim, ele pode duplicar suas chances de ter outro usuário malicioso como o próximo líder.

[00275] As opções para Qr podem ser ainda mais numerosas para o adversário que controla um malicioso. Por exemplo, deixar x, y e z serem três líderes potenciais maliciosos da rodada r

[00276] de modo que

[00277] e seja particularmente pequeno. Isto é, tão pequeno que haja uma boa chance de que seja menor do que a credencial verificada por hash de cada líder potencial honesto. Então, solicitando-se que x oculte sua credencial, o adversário tem uma boa chance de y se tornar o líder da rodada r — 1. Isso implica que ele tem outra opção para Qr: a saber, . Similarmente, o Adversário pode solicitar que tanto x quanto y retenham suas credenciais, de modo que z se torne o líder da rodada r — 1, ganhando outra opção para Qr: a saber,

[00278] Certamente, entretanto, cada uma dessas e outras opções tem uma chance não zero de falhar, devido ao fato de que o adversário não pode prever o hash das assinaturas digitais dos usuários potenciais honestos.

[00279] Uma análise do tipo cadeia de Markov cuidadosa mostra que, não importa quais opções o adversário escolhe fazer na rodada r — 1, contanto que ele não possa injetar novos usuários no sistema, ele não pode diminuir a probabilidade de um usuário honesto ser o líder da rodada r + 40 muito abaixo de h. Essa é a razão pela qual é exigido que os líderes potenciais da rodada r sejam usuários já existentes na rodada r — k. É um modo de garantir que, na rodada r — k, o adversário não possa alterar em muito a probabilidade de que um usuário honesto se torne o líder da rodada r. De fato, não importa quais usuários ele possa adicionar ao sistema nas rodadas r — k a r, eles são inelegíveis para se tornarem líderes potenciais (e, a fortiori, o líder) da rodada r. Assim, o parâmetro de retrospectiva k é, ultimamente, um parâmetro de segurança. (Embora, como pode se ver na seção ??, o mesmo possa também ser um tipo de “parâmetro de conveniência”).

[00280] Chaves Temporária Embora a execução do protocolo não possa gerar uma bifurcação, exceto com probabilidade insignificante, o adversário poderia gerar uma bifurcação, no r-ésimo bloco, após o bloco legítimo r ter sido gerado.

[00281] Aproximadamente, uma vez que Br foi gerado, o Adversário aprendeu quem são os verificadores de cada etapa da rodada r. Assim, ele poderia, portanto, corromper todos eles e obrigá-los a certificar um novo bloco . Já que esse bloco falso pode ser propagado apenas após o legítimo, os usuários que têm prestado atenção não seriam enganados.8 No entanto, seria sintaticamente correto, e é desejado que seja impedido 8 Considere corromper o âncora de notícias de uma grande rede de TV e produzir e transmitir hoje um noticiário que mostra a secretária Clinton ganhando a última eleição presidencial. A maioria reconheceria isso como uma farsa. Mas alguém saindo de um coma pode ser enganada.

de ser fabricado.

[00282] Faz-se isso por meio de uma nova regra. Essencialmente, os membros do conjunto de verificador SVr,s de uma etapa s da rodada r usam chaves públicas temporárias para assinar digitalmente suas mensagens. Essas chaves são de uso único apenas e suas chaves secretas correspondentes são destruídas uma vez que usadas. Desse modo, se um verificador for corrompido posteriormente, o Adversário não pode forçá-lo a assinar qualquer outra coisa que ele não tenha assinado originalmente.

[00283] Naturalmente, deve-se garantir que seja impossível para o Adversário computar uma nova chave e convencer um usuário honesto de que a mesma é a chave temporária certa do verificador i ∈ SVr,s para uso na etapa s.

4.2 SUMÁRIO COMUM DE NOTAÇÕES, NOÇÕES E

PARÂMETROS

[00284] Notações

[00285] • r ≥ 0: o número de rodada atual.

[00286] • s ≥ 1: o número de etapa atual na rodada r.

[00287] • Br: o bloco gerado na rodada r.

[00288] • PKr: o conjunto de chaves públicas ao final da rodada r — 1 e no início da rodada r.

[00289] • Sr: a situação do sistema ao final da rodada r — 1 e no início da rodada r.9

[00290] • PAYr: o conjunto de pagamentos contido em Br .

[00291] • líder da rodada r. escolhe o conjunto de Em um sistema que não é síncrono, a noção do "final da rodada r — 1" e 9 "início da rodada r" precisa ser cuidadosamente definida. Matematicamente, PK r e Sr são computados a partir da situação inicial S0 e dos blocos B1, . . . , Br-1.

pagamentos PAYr da rodada r (e determina a próxima Qr).

[00292] • Qr: a semente da rodada r, uma quantidade (isto é, cadeia binária) que é gerada no final da rodada r e é usada para escolher os verificadores para a rodada r + 1. Qr é independente dos conjuntos de pagamentos nos blocos e não pode ser manipulado por

[00293] • SVr,s: o conjunto de verificadores escolhido para a etapa s da rodada r.

[00294] • SVr: o conjunto de verificadores escolhido para a rodada r,

[00295] • MSVr,s e HSVr,s: respectivamente, o conjunto de verificadores maliciosos e o conjunto de verificadores honestos em SVr,s.

e

[00296] • e respectivamente, os números esperados de líderes potenciais em cada SVr,1 e os números esperados de verificadores em cada SVr,s, para s > 1.

[00297] Note que n1 << n, já que se precisa de pelo menos um membro honesto em SVr,1, mas pelo menos uma maioria de membros honestos em cada SVr,s para s > 1.

[00298] • h ∈ (0, 1): uma constante maior do que 2/3. H é a razão de honestidade no sistema. Isto é, a fração de usuários honestos ou dinheiro honesto, dependendo da suposição usada, em cada Pkrr é pelo menos h.

[00299] • H: uma função de hash criptográfica, modelada como um oráculo aleatório.

[00300] • : Uma cadeia especial do mesmo comprimento que a saída de H.

[00301] • F ∈ (0, 1): o parâmetro que especifica a probabilidade de erro permitida. Uma probabilidade ≤ F é considerada “insignificante”, e uma probabilidade ≥ 1 — F é considerada “grande”.

[00302] • ph ∈ (0, 1): a probabilidade de que o líder de uma rodada r, é honesto. Idealmente, ph — h. Com a existência do Adversário, o valor de ph será determinado na análise.

[00303] • o parâmetro de retrospectiva. Isto é, a rodada r — k é quando os verificadores para a rodada r são escolhidos dentre — a 10 saber,

[00304] • p1 ∈ (0, 1): para a primeira etapa da rodada r, um usuário na rodada r — k é escolhido para estar em SVr,1 com probabilidade

[00305] • p ∈ (0, 1): para cada s > 1 da rodada r, um usuário na rodada r — k é escolhido para estar em SVr,s com probabilidade

[00306] • CERTr: o certificado para Br. O mesmo é um conjunto de assinaturas tH de H(Br) de verificadores apropriados na rodada r.

[00307] • é um bloco provado.

[00308] Um usuário i conhece Br se ele possuir (e verificar de modo bem-sucedido) ambas as partes do bloco provado. Note que o CERTr visto por diferentes usuários pode ser diferente.

[00309] • o tempo (local) em que um usuário i conhece Br. No protocolo de Algorand, cada usuário tem seu próprio relógio. Os relógios de diferentes usuários não precisam estar sincronizados, mas devem ter a mesma velocidade. Apenas para o propósito da análise, considera-se um relógio de referência e se mede os tempos relacionados dos jogadores em relação ao mesmo.

[00310] • e , respectivamente, o tempo (local) em que 10 Falando-se estritamente, "r — k" deve ser "max{0,r — k}”.

um usuário i inicia e termina sua execução da etapa s da rodada r.

[00311] • Λ e λ: essencialmente, limites superiores para, respectivamente, o tempo necessário para executar a etapa 1 e o tempo necessário para qualquer outra etapa do protocolo de Algorand.

[00312] O parâmetro Λ define o limite superior do tempo para propagar um único bloco de 1 MB.

[00313] O parâmetro λ define o limite superior do tempo para propagar uma pequena mensagem por verificador em uma Etapa s > 1.

[00314] Supõe-se que Λ ≤ 4λ.

[00315] Noções

[00316] • Seleção de verificador.

[00317] Para cada rodada r e etapa Cada usuário i ∈ PKr-k computa privadamente sua assinatura com o uso de sua chave de longo prazo e decide se i ∈ SVr,s ou não. Se i ∈ SVr,s, então, é a credencial (r, s) de i, compactamente denotada por

[00318] Para a primeira etapa da rodada r, SVr,1 e são similarmente definidos, com p substituído por p1. Os verificadores em SVr,1 são líderes potenciais.

[00319] • Seleção de líder.

[00320] O usuário i ∈ SVr,1 é o líder da rodada r, denotado por para todos os líderes potenciais j ∈ SVr,1. Sempre que os hashes de duas credenciais de jogadores são comparados, no evento improvável de vínculos, o protocolo sempre quebra os vínculos lexicograficamente de acordo com (as chaves públicas de longo prazo dos) líderes potenciais.

[00321] Por definição, o valor de hash da credencial do jogador é também o menor dentre todos os usuários em PKr-k. Note que um líder potencial não pode decidir privadamente se ele é o líder ou não, sem ver as credenciais dos outros líderes potenciais.

[00322] Já que os valores de hash são uniformes aleatoriamente, quando SVr,1 não é vazio, sempre existe e é honesto com probabilidade de pelo menos h. O parâmetro n1 é grande o suficiente para garantir que cada SVr,1 não seja vazio com grande probabilidade.

[00323] • Estrutura de bloco.

[00324] Um bloco não vazio é da forma e um bloco vazio é da forma

[00325] Note que um bloco não vazio pode ainda conter um conjunto de pagamentos vazio PAYr, se nenhum pagamento ocorrer nessa rodada ou se o líder for malicioso. Entretanto, um bloco não vazio implica que a identidade de sua credencial e foram todos revelados com o tempo. O protocolo garante que, se o líder for honesto, então, o bloco não será vazio com grande probabilidade.

[00326] • Semente Qr.

[00327] Se Br não for vazio, então, , de outro modo,

[00328] Parâmetros

[00329] • Relações entre vários parâmetros.

[00330] — Os verificadores e líderes potenciais da rodada r são selecionados dentre os usuários em PKr-k, em que k é escolhido de modo que o adversário não possa prever Qr-1 de volta à rodada r — k - 1 com probabilidade melhor do que F: de outro modo, ele será capaz de introduzir usuários maliciosos para a rodada r — k, todos os quais serão líderes potenciais/verificadores na rodada r, sucedendo em ter um líder malicioso ou uma maioria maliciosa em SVr,s para algumas etapas s desejadas por ele.

[00331] — Para a etapa 1 de cada rodada r, n1 é escolhido de modo que, com grande probabilidade,

[00332] • Escolhas exemplificativas de parâmetros importantes.

[00333] — As saídas de H têm 256 bits de comprimento.

[00334] — h = 80%, n1 = 35.

[00335] — Λ = 1 minuto e = 15 segundos.

[00336] • Inicialização do protocolo.

[00337] O protocolo começa no tempo 0 com r = 0. Já que não existe “B-1” ou “CERT-1”, sintaticamente, B-1 é um parâmetro público com seu terceiro componente especificando Q-1, e todos os usuários conhecem B-1 no tempo 0. 5 ALGORAND’1

[00338] Nessa seção, é construída uma versão de Algorand' que funciona sob a suposição a seguir.

[00339] SUPOSIÇÃO DE MAIORIA HONESTA DE USUÁRIOS: Mais do que 2/3 dos usuários em cada PKr são honestos.

[00340] Na seção ??, é mostrado como substituir a suposição acima pela suposição de Maioria Honesta de Dinheiro.

5.1 NOTAÇÕES E PARÂMETROS ADICIONAIS

[00341] Notações

[00342] • o número máximo de etapas no protocolo de BA binário, um múltiplo de 3.

[00343] • uma variável aleatória que representa o número de testes de Bernoulli necessários para ver um 1, quando cada teste é 1 com probabilidade e há, no máximo m/3 testes.

[00344] Se todos os testes falharem, então, . Lr será usado para definir o limite superior do tempo necessário para gerar o bloco

Br.

[00345] • o número de assinaturas necessárias nas condições finais do protocolo.

[00346] • CERTr: o certificado para Br. O mesmo é um conjunto de assinaturas tH de H(Br) de verificadores apropriados na rodada r.

[00347] Parâmetros

[00348] • Relações entre vários parâmetros.

[00349] — Para cada etapa s > 1 da rodada r, n é escolhido de modo que, com grande probabilidade, e

[00350] Quando mais próximo de 1 o valor de h está, menor n precisa ser. Em particular, usa-se (variantes de) limites de Chernoff para garantir que as condições desejadas se mantenham com grande probabilidade.

[00351] — m é escolhido de modo que Lr < m/3 com grande probabilidade.

[00352] • Escolhas exemplificativas de parâmetros importantes.

[00353] — F = 10-12.

[00354] — n ≈ 1500, k = 40 e m = 180.

5.2 IMPLANTAÇÃO DE CHAVES TEMPORÁRIAS EM ALGORAND’1

[00355] Conforme já mencionado, deseja-se que um verificador i ∈ SVr,s assine digitalmente sua mensagem da etapa s na rodada r, em relação a uma chave pública temporária com o uso de uma chave secreta temporária que ele destrói prontamente após o uso. Assim, é necessário um método eficiente para garantir que cada usuário possa verificar que é, de fato, a chave para verificar a assinatura de i de .

Isso é feito por um (ao melhor entendimento) novo uso de esquemas de assinatura baseada em identidade.

[00356] A um alto nível, em tal esquema, uma autoridade central A gera uma chave mestre pública, PMK, e uma chave mestre secreta correspondente, SMK. Dada a identidade, U, de um jogador U, A computa, por meio da SMK, uma chave de assinatura secreta skU em relação à chave pública U1, e fornece privadamente skU a U. (De fato, em um esquema de assinatura digital baseada em identidade, a chave pública de um usuário U é o próprio U!) Desse modo, se A destruir a SMK após computar as chaves secretas dos usuários que ele deseja habilitar a produzir assinaturas digitais e não manter qualquer chave secreta computada, então, U é o único que pode assinar digitalmente as mensagens em relação à chave pública U. Assim, qualquer um que saiba “o nome de U” sabe automaticamente a chave pública de U e pode, assim, verificar as assinaturas de U (usando possivelmente também a chave mestre pública PMK).

[00357] Neste pedido, a autoridade A é o usuário i, e o conjunto de todos os usuários possíveis U coincide com o par de rodada-etapa (r, s) em — por exemplo — em que r' é uma determinada rodada, e m + 3 o limite superior para o número de etapas que podem ocorrer dentro de uma rodada. Desse modo, de modo que todos que veem a assinatura de i possam, com grande probabilidade, verificar imediatamente o mesmo para o primeiro milhão de rodadas r após r'.

[00358] Em outras palavras, i gera primeiro PMK e SMK. Então, ele publica que PMK é a chave pública mestre de i para qualquer rodada r e usa SMK para produzir e privadamente armazenar a chave secreta para cada triplo (i, r, s) ∈ S. Com isso feito, ele destrói a SMK.

Se ele determinar que ele não é parte de SVr,s, então, i pode deixar sozinho (na medida que o protocolo não exige que ele autentique qualquer mensagem na etapa s da rodada r). De outro modo, i usa primeiramente para assinar digitalmente sua mensagem e, então, destrói

[00359] Note que i pode publicar sua primeira chave mestre pública quando ele entra pela primeira vez no sistema. Isto é, o mesmo pagamento que leva i ao sistema (em uma rodada r' ou em uma rodada próxima a r') pode também especificar, na solicitação de i, que a chave mestre pública de i para qualquer rodada seja PMK —por exemplo, incluindo um par da forma

[00360] Note também que, já que m+3 é o número máximo de etapas em uma rodada, supondo que uma rodada leva um minuto, o stash das chaves temporárias assim produzidas durará para i por quase dois anos. Ao mesmo tempo, essas chaves secretas temporárias não demorarão muito para serem produzidas por i. Com o uso de um sistema baseado em curva elíptica com 32B chaves, cada chave secreta é computada em alguns microssegundos. Assim, se m + 3 = 180, então, todas as 180M chaves secretas podem ser computadas em menos do que uma hora.

[00361] Quando a rodada atual está se aproximando de para manipular o próximo milhão de rodadas, i gera um novo par de e informa qual é o seu próximo stash de chaves temporárias fazendo-se com que —por exemplo— insira um novo bloco, ou como uma “transação” separada ou como algumas informações adicionais que são parte de um pagamento. Fazendo-se isso, i informa todos de que ele/ela deve usar PMK' para verificar as assinaturas temporárias de i no próximo milhão de rodadas. E assim por diante.

[00362] (Note que, após essa abordagem básica, outros modos para implantar as chaves temporárias sem usar assinaturas baseadas em identidade são certamente possíveis. Por exemplo, por meio de árvores de Merkle.11)

[00363] Outros modos para implantar as chaves temporárias são certamente possíveis — por exemplo, por meio de árvores de Merkle.

5.3 CORRESPONDÊNCIA DAS ETAPAS DE ALGORAND’1 COM AQUELAS DE BA*

[00364] Conforme foi dito, uma rodada em tem no máximo m + 3 etapas.

[00365] ETAPA 1. Nessa etapa, cada líder potencial i computa e propaga seu bloco candidato juntamente com sua própria credencial, .

[00366] Lembre-se que essa credencial identifica explicitamente i. Isso é assim devido ao fato de que

[00367] O verificador potencial i também propaga, como parte de sua mensagem, sua assinatura digital apropriada de . Não lidando com um pagamento ou uma credencial, essa assinatura de i é relacionada a sua chave pública temporária , isto é, ele propaga

[00368] Dadas as convenções, em vez de propagar e ele poderia ter propagado Entretanto, na análise, 11 Nesse método, i gera um par de chaves secreta-pública para cada par de rodada-etapa (r,s) em — por exemplo — Então, ele ordena essas chaves públicas de um modo canônico, armazena a j-ésima chave pública na j-ésima folha de uma árvore de Merkle e computa o valor raiz Ri, que ele publica. Quando ele quer assinar uma mensagem relacionada à chave i não apenas fornece a assinatura real, mas também a trajetória de autenticação para em relação a Ri. Note que essa trajetória de autenticação também prova que é armazenada na j-ésima folha. A partir dessa ideia, o resto dos detalhes pode ser facilmente preenchido.

precisa-se ter acesso explícito a

[00369] ETAPAS 2. Nessa etapa, cada verificador i define para ser o líder potencial cuja credencial verificada por hash é a menor e para ser o bloco proposto por . Já que, visando a eficiência, se deseja concordar com H(Br), em vez de diretamente com Br, i propaga a mensagem que ele teria propagado na primeira etapa de BA* com valor inicial Isto é, ele propaga após assinar temporariamente o mesmo, obviamente. (A saber, após assinar o mesmo em relação à chave pública temporária certa, que nesse caso é Obviamente também, i também transmite sua própria credencial.

[00370] Já que a primeira etapa de BA* consiste na primeira etapa do protocolo consenso classificado GC, a etapa 2 de Algorand' corresponde à primeira etapa do GC.

[00371] ETAPAS 3. Nessa etapa, cada verificador i ∈ SVr,2 executa a segunda etapa de BA*. Isto é, ele envia a mesma mensagem que ele teria enviado na segunda etapa do GC. Novamente, a mensagem de i é temporariamente assinada e acompanhada da credencial de i. (De agora em diante, será omitido que um verificador assina temporariamente sua mensagem e também propaga sua credencial).

[00372] ETAPA 4. Nessa etapa, cada verificador i ∈ SVr,4 computa a saída de GC, (vi, gi) e assina temporariamente e envia a mesma mensagem que ele enviaria na terceira etapa de BA*, isto é, na primeira etapa de BBA*, com o bit inicial 0 se gi= 2, e 1 de outro modo.

[00373] ETAPA s = 5, . . . , m + 2. Tal etapa, se for alcançada, corresponde à etapa s - 1 de BA* e, assim, à etapa s — 3 de BBA*.

[00374] Já que o modelo de propagação é suficientemente assíncrono, deve-se considerar a possibilidade de que, no meio de tal etapa s, um verificador i ∈ SVr,s é alcançado por informações que provam que o bloco Br já foi escolhido. Nesse caso, i interrompe sua própria execução da rodada r de Algorand' e começa a executar suas instruções da rodada-(r + 1).

[00375] Consequentemente, as instruções de um verificador adicionalmente às instruções que correspondem à etapa s — 3 de BBA*, incluem verificar se a execução de BBA* parou em uma etapa s' anterior. Já que BBA* pode apenas parar em uma etapa Moeda Fixada em 0 ou em uma etapa Moeda Fixada em 1, as instruções distinguem se

[00376] A (Condição Final 0): s' — 2 ≡ 0 mod 3, ou

[00377] B (Condição Final 1): s' - 2 ≡ 1 mod 3.

[00378] De fato, no caso A, o bloco Br não está vazio, e, assim, instruções adicionais são necessárias para garantir que i reconstrua apropriadamente Br, juntamente com seu certificado apropriado CERTr. No caso B, o bloco Br está vazio, e, assim, i é instruído a definir e computar CERTr.

[00379] Se, durante sua execução da etapa s, i não vir qualquer evidência de que o bloco Br já foi gerado, então, ele envia a mesma mensagem que ele teria enviado na etapa s — 3 de BBA*.

[00380] ETAPA m + 3. Se, durante a etapa vir que o bloco Br já foi gerado em uma etapa s' anterior, então, ele procede assim como explicado acima.

[00381] De outro modo, em vez de enviar a mesma mensagem que ele poderia ter enviado na etapa m de BBA*, i é instruído, com base nas informações em sua posse, a computar Br e seu certificado correspondente CERTr.

[00382] Lembre-se, de fato, que se define o limite superior do número total de etapas de uma rodada por m + 3.

5.4 O PROTOCOLO REAL

[00383] Lembre-se que, em cada s de uma rodada r, um verificador i ∈ SVr,s usa seu par de chaves pública-secreta de longo prazo para produzir sua credencial, assim como no caso s = 1. O verificador i usa sua chave secreta temporária para assinar sua mensagem (r, s) Para simplicidade, quando r e s são claros, escreve-se em vez de para denotar a assinatura temporária apropriada de i de um valor x na etapa s da rodada r e ESIGi(x) em vez de para denotar . Etapa 1: Proposta de Bloco

[00384] As instruções para cada usuário i ∈ PKr-k: O usuário i inicia sua própria Etapa 1 da rodada r assim que tem conhecimento de Br-1.

[00385] • O usuário i computa Qr-1 a partir do terceiro componente de Br-1 e verifica se ou não.

[00386] • Se então, i interrompe sua própria execução da Etapa 1 imediatamente.

[00387] • Se i ∈ SVr,1, isto é, se i for um líder potencial, então, ele coleta os pagamentos da rodada r que foram propagados a ele até o momento e computa um conjunto de pagamentos máximo a partir dos mesmos. Depois, ele computa seu “bloco candidato” Finalmente, ele computa a mensagem destrói sua chave secreta temporária e, então, propaga

[00388] Observação. Na prática, para encurtar a execução global da etapa 1, é importante que as mensagens (r, 1) sejam seletivamente propagadas. Isto é, para cada usuário i no sistema, para a primeira mensagem (r, 1) que ele recebe e verifica com sucesso,12 o jogador i propaga a mesma como de costume. Para todas as outras mensagens (r, 1) que o jogador i recebe e verifica com sucesso, ele propaga essas apenas se o valor de hash da credencial que as mesmas contêm for o menor dentre os valores de hash das credenciais contidas em todas as mensagens (r, 1) que ele recebeu e verificou com sucesso até o momento. Além disso, conforme sugerido por Georgios Vlachos, é útil que cada líder potencial i também propague sua credencial separadamente: essas mensagens pequenas viajam mais rápido que blocos, garantem propagação oportuna dos , em que as credenciais contidas têm valores de hash pequenos, enquanto fazem aqueles com valores de hash grandes desaparecerem rapidamente.

[00389] Etapa 2: A Primeira Etapa do Protocolo de Consenso Classificado GC

[00390] As instruções para cada usuário i ∈ PKr-k: O usuário i inicia sua própria Etapa 2 da rodada r assim que tem conhecimento de Br-1.

[00391] • O usuário i computa Qr-1 a partir do terceiro componente de Br-1 e verifica se i ∈ SVr,2 ou não.

[00392] • Se então, i interrompe sua própria execução da Etapa 2 imediatamente.

[00393] • Se então após aguardar uma quantidade de tempo i atua conforme segue.

[00394] 1. Ele encontra o usuário de modo que, para todas as credenciais que são parte das mensagens (r, l) 12 Ou seja, todas as assinaturas estão corretas e tanto o bloco quanto seu hash são válidos — embora i não verifique se o conjunto de pagamentos incluído é máximo para seu propositor ou não.

verificadas com sucesso, ele tenha recebido até o momento.13

[00395] 2. Se ele tiver recebido de uma mensagem válida 14 , então i define de outro modo i define 15

[00396] 3. i computa a mensagem destrói sua chave secreta temporária e, então, propaga

[00397] Etapa 3: A Segunda Etapa de GC

[00398] As instruções para cada usuário i ∈ PKr-k: O usuário i inicia sua própria etapa 3 da rodada r assim que tem conhecimento de Br-1.

[00399] • O usuário i computa Qr-1 a partir do terceiro componente de Br-1 e verifica se i ∈ SVr,3 ou não.

[00400] • Se então, i interrompe sua própria execução da etapa 3 imediatamente.

[00401] • Se i ∈ Svr,3,r,3, então após aguardar uma quantidade de tempo i atua conforme segue.

[00402] 1. Se existir um valor de modo que, entre todas as mensagens válidas que ele recebeu, mais de 2/3 das mesmas são da forma sem qualquer contradição,16 então, ele computa a 13 Essencialmente, o usuário i decide privadamente que o líder da rodada r é o usuário l. 14 Novamente, as assinaturas do jogador e os hashes são todos verificados com sucesso, e em é um conjunto de pagamentos válidos para a rodada r — embora i não verifique se é máximo para ou não. 15 A mensagem sinaliza que o jogador i considera como sendo o hash do bloco seguinte ou considera o bloco seguinte como estando vazio. 16 Ou seja, ele não recebeu duas mensagens válidas contendo e um j diferente, respectivamente, de um jogador j. Doravante, exceto nas Condições Finais definidas adiante, sempre que um jogador honesto quiser mensagens de uma dada forma, as mensagens que contradizem umas às outras não são nunca contadas ou consideradas válidas.

mensagem De outro modo, ele computa

[00403] 2. i destrói sua chave secreta temporária e, então, propaga

[00404] Etapa 4: Saída de GC e A Primeira Etapa de BBA*

[00405] Instruções para cada usuário O usuário i inicia sua própria etapa 4 da rodada r assim que tem conhecimento de

[00406] • O usuário i computa a partir do terceiro componente de B e verifica se ou não.

[00407] • Se então, i interrompe sua própria execução da etapa 4 imediatamente.

[00408] • Se então após aguardar uma quantidade de tempo atua conforme segue.

[00409] 1. Ele computa vi e gi, a saída de GC, conforme segue.

[00410] (a) Se existir um valor de modo que, dentre todas as mensagens válidas que recebeu, mais de 2/3 das mesmas são da forma , então, ele define e

[00411] (b) De outro modo, se existir um valor de modo que, dentre todas as mensagens válidas que recebeu, mais de 1/3 das 17 mesmas são da forma , então, ele define e

[00412] (c) De outro modo, ele define e

[00413] 2. Ele computa bi, a entrada de BBA*, conforme segue:

[00414] e de outro modo.

17 Pode ser provado que o v' no caso (b), se existir, precisa ser exclusivo.

[00415] 3. Ele computa a mensagem destrói sua chave secreta temporária e, então, propaga

[00416] A etapa s, 5 ≤ s ≤ m + 2, s - 2 ≡ 0 mod 3: Uma Etapa Moeda Fixada em 0 de BBA*

[00417] Instruções para cada usuário O usuário i inicia sua própria etapa s da rodada r assim que tem conhecimento de Br-1.

[00418] • O usuário i computa Qr-1 a partir do terceiro componente de Br-1 e verifica se i ∈ SVr,s.

[00419] • então, i interrompe sua própria execução da etapa s imediatamente.

[00420] • Se i ∈ SVr,s, então, ele atua conforme segue.

[00421] - Ele aguarda até uma quantidade de tempo ter transcorrido.

[00422] - Condição Final 0: Se, durante tal aguardo e em qualquer ponto no tempo, existir uma série e uma etapa s' de modo que

[00423] (a) mod 3 — ou seja, a etapa s’ é uma etapa Moeda Fixa em 0,

[00424] (b) i recebeu pelo menos mensagens válidas 18 e

[00425] (c) i recebeu uma mensagem válida com v =

[00426] então, i interrompe sua própria execução da etapa s (e, de fato, da rodada r) imediatamente sem propagar nada; define e 18 Tal mensagem do jogador j é contada mesmo se o jogador i tiver também recebido uma mensagem de j que sinaliza 1. Coisas similares para a Condição Final

1. Conforme mostrado na análise, isso é realizado para garantir que todos os usuários honestos conheçam Br dentro do tempo λ a partir um do outro.

define seu próprio CERTr como sendo o conjunto de mensagens da subetapa (b).19

[00427] - Condição Final 1: Se, durante tal aguardo e em qualquer ponto no tempo, existir uma etapa s' de modo que

[00428] mod 3 — ou seja, a etapa s’ é uma etapa Moeda Fixa em 1, e

[00429] (b) i recebeu pelo menos tH mensagens válidas 20

[00430] então, i interrompe sua própria execução da etapa s (e, de fato, da rodada r) imediatamente sem propagar nada; define e define seu próprio CERTr como sendo o conjunto de mensagens da subetapa (b’).

[00431] - De outro modo, ao final do aguardo, o usuário i realiza o seguinte.

[00432] Ele define vi como sendo o voto da maioria do nos segundos componentes de todo válido que recebeu.

[00433] Ele computa bi conforme segue.

[00434] Se mais de 2/3 de todos os válidos que recebeu forem da forma , então, define

[00435] De outro modo, se mais de 2/3 de todos os 19 O usuário i agora conhece Br e sua própria rodada r termina. Ele ainda ajuda a propagar mensagens como um usuário genérico, mas não inicia qualquer propagação como um verificador (r, s). Em particular, ele ajudou a propagar todas as mensagens em seu CERTr, que é suficiente para o presente protocolo. Observa- se que ele deve também definir para o protocolo de BA binário, mas bi não é necessário nesse caso de qualquer forma. Coisas similares pata todas as instruções futuras. 20 Nesse caso, não importa quais sejam.

válidos que recebeu forem da forma , então, define

[00436] De outro modo, define

[00437] Ele computa a mensagem destrói sua chave secreta temporária e, então, propaga

[00438] A etapa s, 6 ≤ s ≤ m + 2, s - 2 ≡ 1 mod 3: Uma Etapa Moeda Fixada em 1 de BBA*

[00439] As instruções para cada usuário i ∈ PKr-k: O usuário i inicia sua própria etapa s da rodada r assim que tem conhecimento de Br-1.

[00440] • O usuário i computa Qr-1 a partir do terceiro componente de Br-1 e verifica se i ∈ SVr,s ou não.

[00441] • Se i ∉ SVr,s, então, i interrompe sua própria execução da etapa s imediatamente.

[00442] • Se i ∈ SVr,s, então, ele realiza o seguinte.

[00443] - Ele aguarda até uma quantidade de tempo ter transcorrido.

[00444] - Condição Final 0: As mesmas instruções que para as etapas Moeda Fixa em 0.

[00445] - Condição Final 1: As mesmas instruções que para as etapas Moeda Fixa em 0.

[00446] - De outro modo, ao final do aguardo, o usuário i realiza o seguinte.

[00447] Ele define vi como sendo o voto da maioria do nos segundos componentes de todo válido que recebeu.

[00448] Ele computa bi conforme segue.

[00449] Se mais de 2/3 de todos os válidos que recebeu forem da forma , então, define

[00450] De outro modo, se mais de 2/3 de todos os válidos que recebeu forem da forma , então, define

[00451] De outro modo, define

[00452] Ele computa a mensagem destrói sua chave secreta temporária e, então, propaga

[00453] A etapa s, 7 ≤ s ≤ m + 2, s - 2 ≡ 2 mod 3: Uma Etapa Moeda Genuinamente Lançada de BBA*

[00454] Instruções para cada usuário i e PKr-k: O usuário i inicia sua própria etapa s da rodada r assim que tem conhecimento de Br-1.

[00455] • O usuário i computa Qr-1 a partir do terceiro componente de Br-1 e verifica se i ∈ SVr,s ou não.

[00456] • Se então, i interrompe sua própria execução da etapa s imediatamente.

[00457] • Se , então, ele realiza o seguinte.

[00458] - Ele aguarda até uma quantidade de tempo ter transcorrido.

[00459] - Condição Final 0: As mesmas instruções que para as etapas Moeda Fixa em 0.

[00460] - Condição Final 1: As mesmas instruções que para as etapas Moeda Fixa em 0.

[00461] - De outro modo, ao final do aguardo, o usuário i realiza o seguinte.

[00462] Ele define vi como sendo o voto da maioria do nos segundos componentes de todo válido que recebeu.

[00463] Ele computa bi conforme segue.

[00464] Se mais de 2/3 de todos os válidos que recebeu forem da forma , então, define

[00465] De outro modo, se mais de 2/3 de todos os válidos que recebeu forem da forma , então, define

[00466] De outro modo, é o conjunto de verificadores (r, s - 1) de quem ele recebeu uma mensagem válida Ele define

[00467] Ele computa a mensagem destrói sua chave secreta temporária e, então, propaga

[00468] Etapa m + 3: A Última Etapa de BBA* 21

[00469] Instruções para cada usuário O usuário i inicia sua própria etapa m + 3 da rodada r assim que tem conhecimento de Br-1.

[00470] • O usuário i computa Qr-1 a partir do terceiro componente de Br-1 e verifica se i ∈ ou não.

[00471] • Se então, i interrompe sua própria execução da etapa m + 3 imediatamente.

[00472] • Se , então, ele realiza o seguinte.

[00473] - Ele aguarda até uma quantidade de tempo ter transcorrido.

21 Com probabilidade enorme, BBA* terminou antes dessa etapa, e especifica-se essa etapa para completeza.

[00474] - Condição Final 0: As mesmas instruções que para as etapas Moeda Fixa em 0.

[00475] - Condição Final 1: As mesmas instruções que para as etapas Moeda Fixa em 0.

[00476] - De outro modo, ao final do aguardo, o usuário i realiza o seguinte.

[00477] Ele define

[00478] Ele computa a mensagem destróis sua chave secreta temporária e, então, propaga para certificar Br. 22

[00479] Reconstrução do Bloco de Rodada r por Não Verificadores

[00480] Instruções para cada usuário i no sistema: O usuário i inicia sua própria rodada r assim que tem conhecimento de Br-1 e aguarda pelas informações do bloco conforme segue.

[00481] Se, durante tal aguardo e em qualquer ponto no tempo, existir uma série v e uma etapa s' de modo que

[00482] (a) mod 3,

[00483] (b) i recebeu pelo menos tH mensagens válidas e

[00484] (c) i recebeu uma mensagem válida

[00485] então, i interrompe sua própria execução da rodada imediatamente; define e define seu próprio CERTr como sendo o 22 Um certificado da etapa m + 3 não tem que incluir ESIG i(outi). Inclui-se isso para uniformidade apenas: os certificados agora têm um formato uniforme, não importando em que etapa são gerados.

conjunto de mensagens da subetapa (b).

[00486] - Se, durante tal aguardo e em qualquer ponto no tempo, existir uma etapa s' de modo que

[00487] (a) mod 3, e

[00488] (b’) i recebeu pelo menos tH mensagens válidas

[00489] então, i interrompe sua própria execução da rodada imediatamente; define e define seu próprio CERTr como sendo o conjunto de mensagens da subetapa (b’).

[00490] - Se, durante tal aguardo e em qualquer ponto no tempo, i tiver recebido pelo menos tH mensagens válidas então, i interrompe sua própria execução da rodada r imediatamente, define e define seu próprio CERTr como sendo o conjunto de mensagens para 1 e 6 ALGORAND COM CHAVES TEMPORÁRIAS

[00491] Essencialmente, em Algorand, os blocos são gerados em rodadas. Em uma rodada r

[00492] (1) Um líder adequadamente credenciado propõe um novo bloco e, então,

[00493] (2) Os usuários adequadamente credenciados executam, em diversas etapas, um protocolo de acordo bizantino adequado (BA) no bloco proposto.

[00494] O protocolo de BA preferencial é BA*. A etapa de proposta do bloco pode ser considerada a etapa 1, de modo que as etapas de BA* sejam 2,3,...

[00495] Apenas um usuário adequado i, selecionado aleatoriamente de acordo entre os usuários no sistema, tem o direito de enviar uma mensagem na etapa s da rodada r. Algorand é muito rápido e seguro devido ao fato de que tal usuário i verifica se ele tem direito de falar. Se esse for o caso, o usuário i obtém na realidade uma prova, uma credencial. Se for sua vez de falar na etapa s da rodada r, i propaga na rede tanto sua credencial e quanto mensagem digitalmente sinalizada. A credencial prova a outros usuários que eles devem considerar a mensagem

[00496] Uma condição necessária para o usuário i ter o direito de falar na etapa s da rodada r é que ele já estava no sistema algumas rodadas atrás. Especificamente, k rodas antes da rodada r, em que k é um parâmetro denominado o parâmetro de “retrospectiva”. Ou seja, para ser elegível para falar na rodada r, i precisa pertencer ao PKr-k, o conjunto de todas as chaves públicas/usuários já no sistema na rodada r - k. (Os usuários podem ser identificados com suas chaves públicas.) Essa condição é fácil de verificar no sentido de que é uma forma derivável do blockchain.

[00497] A outra condição é que

[00498] em que p é uma dada probabilidade que controla o número esperado de verificadores em SVr,s, ou seja, o conjunto de usuários com direito de falar na etapa s da rodada r. Se essa condição for satisfeita, então, a credencial de i é definida como sendo

[00499] Obviamente, apenas i pode descobrir se pertence a SVr,s, todos os outros usuários, que não têm conhecimento da chave de sinalização secreta de i, não têm ideia da mesma. Entretanto, se i ∈ SVr,s, então, i pode demonstrar que esse é o caso para qualquer um por propagação de sua credencial dado o blockchain até o momento.

Recorda-se o fato de que (1) Qr-1 é facilmente computável a partir do bloco anterior, Br-1, embora suficientemente muitos blocos essencialmente imprevisíveis antes, e (2) qualquer um pode verificar assinaturas digitais de i (em relação a sua chave a longo prazo no sistema).

[00500] Recorda-se também que, nas versões de Algorand até o momento, um verificador i ∈ SVr,s sinaliza digitalmente suam mensagem de etapa-s-rodada-r em relação a uma chave pública temporária que qualquer um pode, dado o blockchain, perceber genuinamente que corresponde a i e etapa s da rodada r. Essa “assinatura temporária” é denotada por que está usando letras minúsculas de modo a diferenciar a mesma das assinaturas de i com sua chave “a longo prazo”, que são denotadas por letras maiúsculas.

[00501] Em suma, um usuário em SVr,s propaga duas mensagens separadas na etapa s da rodada r: (a) essa credencial e (b) sua mensagem de etapa-s-rodada-r sinalizada digitalmente (de modo temporário) , Após fazê-lo, i deleta sua chave temporária secreta correspondente a

[00502] Esse uso de chaves temporárias impede que um adversário que corrompe suficientemente muitos verificadores de rodada r após o bloco Br ter sido produzido pode gerar um bloco de rodada r diferente.

[00503] Recorda-se que, de fato, os verificadores da etapa 1 são os líderes potenciais e que suas mensagens de etapa-1-rodada-r são os blocos que propõe. (O líder de rodada r é definido como sendo o líder potencial cuja credencial verificada por hash é menor. No caso de empates improváveis, pode-se escolher o líder potencial que é lexicograficamente o primeiro.) Para qualquer etapa s > 1, a mensagem é sua “mensagem de controle”, ou seja, sua mensagem no protocolo de BA BA*.

[00504] Separar uma credencial de i verificador dessa mensagem (digitalmente sinalizada) tem duas vantagens principais:

[00505] A1 Garante que, na primeira etapa, em que diversos líderes potenciais propagam sua novos blocos propostos, os usuários podem identificar rapidamente o líder de rodada quando ele é honesto. De fato, todas as credenciais, e em particular as credenciais para a etapa 1, são muito pequenas, enquanto os blocos propostos podem ser grandes. (O bloco real proposto por pode ser identificado pouco depois.)

[00506] A2 Possibilita a implantação de honestidade preguiçosa. Ou seja, possibilita que um usuário i perceba secretamente em antecipação em quais rodadas e etapas precisam atuar. 7 ALGORAND COM BLOCKCHAINS CREDENCIADOS POR

MENSAGEM

[00507] Descreve-se primeiramente uma nova modalidade de Algorand que dispensa o uso de chaves temporárias para certificar por fim um bloco, mas usa chaves temporárias para todas as outras etapas.

[00508] Então, será descrito agora como se livrar de chaves temporárias em Algorand em todas as etapas, mas a primeira etapa de proposta de bloco.

[00509] Proposta de Bloco A nova modalidade usa a mesma etapa 1 que a anterior. Assim, um líder potencial i da rodada r sinaliza seu bloco proposto em relação a sua chave temporária correspondente; apaga a chave temporária secreta correspondente; e, então, propaga sua própria credencial e assinatura de

[00510] Acordo Bizantino Em uma rodada r, cada etapa s do protocolo de BA* permanece a mesma que a anterior. Assim, em particular, um verificador propaga sua credencial e sua própria mensagem de etapa-s-rodada-r sinalizada digitalmente em relação à sua chave pública temporária r-s e apaga a chave temporária secreta correspondente. Entretanto, a alteração seguinte é aplicada à condição final da primeira etapa moeda fixada em 1 e todas as etapas subsequentes de BBA*.

[00511] Assume-se que um usuário i, em tal etapa s, atingiu a condição final para o primeiro tempo. Então, esse pode ser o caso em que

[00512] • para algum bit b, i recebeu pelo menos tH mensagens válidas com o mesmo e

[00513] • i recebeu uma mensagem válida com

[00514] Consequentemente, se i for um verificador em SVr,s, então, em modalidades anteriores de Algorand, o mesmo poderia interromper a execução imediatamente e poderia aprender o bloco Br, para o qual ele poderia estar em posse de CERTr. Recorda-se que CERTr consistiu em dado número de assinaturas digitais temporárias. Agora é feita referência a tal CERTr como um “certificado temporário” de Br.

[00515] Na nova modalidade de Algorand, o usuário i pode ser um usuário arbitrário em em que k é um parâmetro de retrospectiva, em vez de um verificador em SVr,s (que necessariamente pertence a Tal usuário arbitrário agora não interrompe mais i (simulação) sua execução da rodada r. Em vez disso, com o uso de sua chave secreta a longo prazo, ele produz uma assinatura de dados que indica que considera o bloco B como sendo final e que garante que a assinatura tem uma chance adequada de ser considerada adequadamente. Por exemplo, sem qualquer limitação pretendida, i computa

[00516] em que B é o último bloco recém-constituído no blockchain. Se H(si) < p, então, i propaga Sj, e denomina-se s como uma assinatura de certificação credenciada. (Aqui, p é um dado parâmetro em [0, 1].)

[00517] Um dado limite T de tais assinaturas constitui um certificado não temporário para B.

[00518] Agora, apenas certificados não temporário realmente importam. Os certificados temporários podem ser considerados apenas uma “trampolim” em direção aos certificados não temporários reais.

[00519] Um usuário honesto, que vê um certificado final para um bloco Br, não contribui mais para a geração ou certificação final de um bloco da rodada r.

[00520] Análise Ainda que certificados não temporários consistam em assinaturas a longo prazo, a modalidade permanece segura. Essencialmente, isso ocorre devido ao fato de que, para escolhas adequadas de p e T, o adversário não pode viavelmente encontrar qualquer série X para a qual possa produzir T assinaturas Sj da forma

[00521] em que todos j são usuários corrompidos e H(sj) ≤ p.

[00522] (Nessa aplicação, T poderia ser bem pequeno — por exemplo, cerca de 500. Isso ocorre devido ao fato de que é suficiente que pelo menos uma das T assinaturas é de um usuário honesto. De fato, T pode ser muito menor devido ao fato de que é suficiente produzir certificados não temporários muito frequentemente, mas não necessariamente para cada bloco.)

[00523] Observa-se também que, na nova modalidade, o adversário não pode inundar a rede obrigando usuários honestos a propagar “assinaturas de certificação credenciadas arbitrárias” computadas por usuários corrompidos. De fato, embora qualquer j ∈ PKr-k malicioso pudesse encontrar alguma série arbitrária Xj de modo que por um uso adequado de regras de propagação, a assinatura nunca será retransmitida por um usuário honesto. De fato, um usuário u encaminhará uma assinatura não apenas se (1) e (2) , mas também se (3) H (B) for o hash de um bloco B para o qual o próprio u viu um certificado não temporário.

[00524] De fato, seria possível substituir a condição 3 acima pela seguinte mais fraca:

[00525] 3'. H(B) é o hash de um bloco B para o qual o próprio u viu um subconjunto suficientemente grande de um certificado temporário possível.

[00526] De fato, quando um usuário honesto i viu um certificado temporário completo para B, então (na ausência de partições), os outros usuários honestos precisam ter visto B aprovado por um grande número de verificadores da etapa adequada. Esse número é realmente suficiente para identificar o único bloco que tem uma chance de ser certificado de modo não temporário.

[00527] Eliminação de Chaves Temporárias em Outras Etapas A modalidade acima exige um número mínimo de alterações ao protocolo de Algorand original. Explica-se agora como evitar chaves temporárias em cada etapa, exceto a primeira. A ideia é que, para cada etapa s > 1, não há verificadores de etapa-s. Em vez disso, para cada rodada r, cada usuário executa internamente a etapa s como se fosse um verificador em SVr,s, de modo a computar internamente sua mensagem de etapa-s-rodada-r. Nesse ponto, em vez de sinalizar digitalmente com sua chave temporária verifica se tem o direito de propagar a mensagem conforme segue.

Primeiramente, i verifica se ele estava no sistema k rodadas atrás: ou seja, se Se esse for o caso, então, i sinaliza digitalmente com sua chave a longo prazo, juntamente com a quantidade Qr-1; por exemplo, computa e verifica se o hash dessa assinatura é ≤ p, para uma dada probabilidade p. Se esse for o caso, então, i tem o direito de propagar e realmente propaga, Observa-se que dado , qualquer um pode verificar que i tinha o direito de propagar . Na etapa s + 1, os usuários apenas consideram mensagens de etapa-s propagadas pelos usuários com direito.

[00528] Um usuário honesto, que tem (pelo menos internamente) a etapa executada s da rodada r, não executa ou participa mais da execução a tal etapa. 8 ESCOPO

[00529] Note que o mecanismo descrito no presente documento é aplicável a outros sistemas de blockchain em que é desejável escolher aleatoriamente um subconjunto de usuários para um propósito particular, tal com verificação, de um modo geralmente verificável. Assim, o sistema descrito no presente documento pode ser adaptado a outros esquemas de blockchain, tais como Ethereum ou Litecoin, ou até mesmo esquemas de blockchain que não se relacionam diretamente à moeda.

[00530] O sistema descrito no presente documento pode ser adaptado para ser aplicado e combinado com mecanismos apresentados em qualquer um ou todos dentre os documentos no PCT/US2017/031037, depositado em 4 de maio de 2017, 15/551.678 depositado em 17 de agosto de 2017, 62/564.670 depositado em 28 de setembro de 2017, 62/567.864 depositado em 4 de outubro de 2017, 62/570.256 depositado em 10 de outubro de 2017, 62/580.757 depositado em 2 de novembro de 2017, 62/607.558 depositado em 19 de dezembro de 2017, 62/632.944 depositado em 20 de fevereiro de 2018 e 62/643.331 depositado em 15 de março de 2018, todos os quais estão incorporados a título de referência ao presente documento.

[00531] As implementações de software do sistema descrito no presente documento podem incluir código executável que é armazenado em um meio legível por computador e executado por um ou mais processadores. O meio legível por computador pode ser não temporário e incluir um disco rígido de computador, ROM, RAM, memória flash, mídia de armazenamento de computador portátil, tal como um CD-ROM, um DVD-ROM, um pen drive, um cartão SD e/ou outra unidade com, por exemplo, uma interface de barramento serial universal (USB), e/ou qualquer outra memória de computador ou meio legível por computador não temporário ou tangível apropriado em que código executável pode ser armazenado e executado por um processador. O sistema descrito no presente documento pode ser usado em conexão com qualquer sistema operacional apropriado.

[00532] Outras modalidades da invenção serão evidentes às pessoas versadas na técnica a partir de uma consideração do relatório descritivo ou da prática da invenção revelada no presente documento. Pretende-se que o relatório descritivo e os exemplos sejam considerados como exemplificadores apenas, sendo que o escopo e espírito verdadeiro da invenção são indicados pelas reivindicações a seguir.

Claims (16)

REIVINDICAÇÕES

1. Método para, em um sistema de transação em que transações são organizadas em blocos, uma entidade construir um novo bloco Br de transações válidas, em relação a uma sequência de blocos anteriores B0, B1, . . . , Br-1, em que o método é caracterizado pelo fato de que compreende: fazer a entidade determinar uma quantidade Q dos blocos anteriores; fazer a entidade usar uma chave secreta a fim de computar uma série S exclusivamente associada a Q e a entidade; fazer a entidade computar a partir de S uma quantidade T que é pelo menos um dentre: a própria S, uma função de S e um valor de hash de S; fazer a entidade determinar se T possui uma dada propriedade; e se T possuir a dada propriedade, fazer a entidade sinalizar digitalmente Br e tornar disponível S e uma versão digitalmente sinalizada de Br, em que a entidade é selecionada com base em um valor aleatório que varia de acordo com uma assinatura digital de Br.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a chave secreta é uma chave de sinalização secreta correspondente a uma chave pública da entidade e S é uma assinatura digital de Q pela entidade.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que T é um número e satisfaz a propriedade se T for menor que um dado número p.

4. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que S é disponibilizado tornando-se S deduzível a partir de Br.

5. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que cada usuário tem um balanço no sistema de transação, e p varia para cada usuário de acordo com o balanço de cada usuário.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o valor aleatório é um hash da assinatura digital da entidade.

7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que a entidade é selecionada se o valor aleatório estiver abaixo de um limite que é escolhido para fazer com que um número mínimo de entidades do sistema de transação possa sinalizar digitalmente Br.

8. Método para selecionar um subconjunto de usuários em um sistema de blockchain para verificar um novo bloco Br em relação a uma sequência de blocos anteriores B0, B1, . . . , Br-1, em que o método é caracterizado pelo fato de que compreende: fazer com que pelo menos alguns dos usuários sinalizem digitalmente o novo bloco Br juntamente com outras informações para produzir uma assinatura digital; fazer com que pelo menos alguns dos usuários determinem um valor de hash da assinatura digital; fazer com que pelo menos alguns dos usuários comparem o valor de hash a um limite predeterminado; e fazer com que o subconjunto dos usuários disponibilize a assinatura digital para verificar o novo bloco Br em resposta ao valor de hash estar abaixo de um limite predeterminado para cada um dentre o subconjunto dos usuários.

9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que um usuário particular dentre os usuários sinaliza digitalmente o novo bloco Br apenas se o usuário particular dentre os usuários verificar as informações fornecidas no novo bloco Br.

10. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que o valor predeterminado é escolhido para fazer com que o subconjunto dos usuários contenha um número mínimo dos usuários.

11. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que o sistema de blockchain é usado em um sistema de transação em que as transações são organizadas em blocos.

12. Método em um blockchain para causar certificação de pelo menos uma série de dados m, em que o método é caracterizado pelo fato de que compreende: fazer um conjunto S de usuários verificar se m possui pelo menos uma dada propriedade; fazer usuários sinalizarem digitalmente m, em resposta à verificação de m pelos usuários; e fazer os usuários disponibilizarem as assinaturas digitais de m que são assinaturas credenciadas de m.

13. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que a assinatura digital de m é credenciada se a assinatura digital satisfizer uma dada propriedade adicional.

14. Método, de acordo com a reivindicação 13, caracterizado pelo fato de que a assinatura digital de m satisfaz a dada propriedade adicional se um hash da assinatura digital for menor que um dado número alvo.

15. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que a série de dados m é certificada por pelo menos um dado número de assinaturas credenciadas de m.

16. Software de computador, fornecido em um meio legível por computador não transitório, caracterizado pelo fato de que compreende: código executável que implanta o método, de acordo com qualquer uma das reivindicações 1 a 15.